You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/06/10 10:21:59 UTC
[proposal] avalon 5 ComponentManager interface
Summary:
- proposal for component management in avalon 5:
1) removal of ComponentSelector
2) removal of release()
3) replacement of Component with Object
4) replacement of ComponentException with exists() for lookup()
5) addition of an _optional_ lookup() method that supports hints, to
enable smooth migration from ComponentSelector usage
- rationale behind proposal. #5 is point of debate. Current proposal
allows smooth migration for Cocoon and other client code; I cannot think
of a better way to allow this.
- analysis of backwards-compatibility. Changes are required, but they're
not world-shocking and it should be possible to write a tool to
automatically make 99% of these changes.
- course of action
cheers!
Leo Simons
PROPOSAL
========
/**
* A ComponentManager is a simple lookup mechanism for
* {@see $Components Components}. The lookup key is a {@see $Role role},
* possibly with a hint to further specify the lookup. Support for hints
* in ComponentManager implementations is optional.
*
* <p>Typical usage:</p>
*
* <pre>
* // inside your Component...
* compose( ComponentManager cm ) throws ComponentException
* {
* if( cm.exists( MyComponent.ROLE ) )
* m_myComponent = cm.lookup( MyComponent.ROLE );
*
* // more simple (no-hint) lookups here.
*
* // if the lookups below result in exceptions, the container will
* // know what to do
*
* if( cm.exists( AnotherComponent.ROLE,
* AnotherComponent.SOME_HINT ) )
* m_anotherComponent = cm.lookup( AnotherComponent.ROLE,
* AnotherComponent.SOME_HINT );
* }
* // ...
* </pre>
*/
interface ComponentManager
{
/**
* Look up a component. Make sure to verify it exists using
* the exists() method before you do the lookup.
*
* @throws IllegalArgumentException if there is no component
* inside the ComponentManager implementing the specified role.
*/
Object lookup( String role );
/**
* Look up a component. Make sure to verify it exists using
* the exists() method before you do the lookup.
*
* @throws UnsupportedOperationException if the
* ComponentManager implementation does not support hints.
*
* @throws IllegalArgumentException if there is no component
* inside the ComponentManager implementing the specified role
* with the specified hint.
*/
Object lookup( String role, String hint );
/**
* Determine whether a component with the specified
* role exists in this ComponentManager.
*/
boolean exists( String role );
/**
* Determine whether a component with the specified
* role exists in this ComponentManager.
*
* @throws UnsupportedOperationException if the
* ComponentManager implementation does not support hints.
*/
boolean exists( String role, String hint );
}
RATIONALE
=========
Discussions in January 2002 leading to the creation of the
ServiceManager and recent discussions of avalon 5 raise some issues.
Why no ComponentException?
==========================
Since the ComponentManager is a simple lookup mechanism, the only
possible cause for an error during lookup is that of a requested
component not existing. The use of exists() follows common java
practice, is clear to the API user and results in clean, performant
code.
While making ComponentException extend RuntimeException would likely be
of no difference to the component developer, it seems more natural to
remove it here, as IllegalArgumentException describes the problem
perfectly.
Why a lookup with a hint?
=========================
Even though some of us may not like the use of hints, removing the
concept of the ComponentSelector *and* no support for hints means that
applications that used the ComponentSelector will have a very tough
migration path.
The introduction of hints does not hurt applications that do not need
them, and allowing the IllegalArgumentException explicitly means that
Containers have a simple mechanism for handling the case where they do
not support them while a contained component does (the container passes
in a CM that doesn't support hints, which results in an
IllegalArgumentException during compose() in the component, which the
container then catches and handles as appropriate).
Why no release()?
=================
The release() method has to do with resource management, which is not
the concern of the ComponentManager. See recent discussions.
Why no Component interface?
===========================
The Component interface is a marker interface, which is considered a bad
way to provide information on components, as it causes problems when
integrating with existing component-oriented products like CORBA and
EJB. See the discussions in January that led to creation of the
ServiceManager.
Why no ComponentSelector?
=========================
See on-and-off discussion of this subject over the past 2 years. It
requires horrid-looking, complex, client code.
The Selector concept is replaced with the concept of lookup hints. While
some of us believe (myself included) that the use of hints/sub-selectors
in a directory-style lookup is a design fault, a provision for them
should be made as client code depends on its existence.
BACKWARD COMPATIBILITY ISSUES
=============================
This change will require oversee-able changes to client source code.
Migrating from Avalon 4 ComponentManager
========================================
Is relatively painless. Though it would be best to replace all
occurrences of "lookup([-_0-9a-zA-Z]);" with "if(exists($1))
lookup($1);", if the application is assembled well, this is not
necessary as the requested components will always be available.
Another thing that needs to be done is to add the cast from Object to
Component in all places where you use the Component interface. This is
the same effort required when upgrading from a4 ComponentManager to a4
ServiceManager; it has been agreed upon in January 2002 this change is a
good thing.
Also, all calls to release() must be removed. This is not likely to
cause problems.
Migrating from Avalon 4 ServiceManager
======================================
Is relatively painless. Though it would be best to replace all
occurrences of "lookup([-_0-9a-zA-Z]);" with "if(exists($1))
lookup($1);", if the application is assembled well, this is not
necessary as the requested components will always be available.
Also, all calls to release() must be removed. This is not likely to
cause problems.
Finally, all mention of ServiceManager must revert back to
ComponentManager.
Migrating from Avalon 4 ComponentManager + ComponentSelector
============================================================
Is the most difficult upgrade path, as all uses of ComponentSelector
should be replaced by the use of hints. Typical example:
// inside your Component...
compose( ComponentManager cm ) throws ComponentException
{
// ...
ComponentSelector selector = (ComponentSelector)
cm.lookup(MyComponent.ROLE + "Selector");
myComponent = (MyComponent)selector.select(
MyComponent.SOME_HINT);
// ...
}
// ...
// inside your Component...
compose( ComponentManager cm )
{
// ...
if( cm.exists( MyComponent.ROLE,
MyComponent.SOME_HINT ) )
m_myComponent = cm.lookup( MyComponent.ROLE,
MyComponent.SOME_HINT );
// ...
}
// ...
Migration Automation
====================
It should be possible to write migration tools that automate this
upgrade process.
COURSE OF ACTION
================
(on proposal acceptance)
- The next release of Avalon Framework v4 should document the changes we
intend to make, so component developers can anticipate the changes that
will need to be made to migrate to v5.
- The interface should be added to the v5 proposal
- evaluation of the necessity of a migration tool should be evaluated
and added to the TODO list if it is considered required.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> ><snip/>
> >3) replacement of Component with Object
> ><snip/>
> >
> <delurk>
> *Object* is a loaded word and may, or may not, introduce much potential
> confusion. Kind of like the word *interface* in that respect. Though
> this choice would have no bad effect on core guys such as Berin, Leos or
> Peters, may or may not present an un-necessary obstacle (?) to the
> outside world coming in.
>
> If there was a better choice available, that might be worth considering.
>
> On an unrelated note, it has been fascinating watching the back and
> forth here lately. Leaves no doubt that Avalon is being developed with
> much care and attention to detail.
> </delurk>
Don't worry: we talk of removing the interface Component, not the
concept or the term =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Leo Simons wrote:
>Summary:
>
>- proposal for component management in avalon 5:
>
><snip/>
>3) replacement of Component with Object
><snip/>
>
<delurk>
*Object* is a loaded word and may, or may not, introduce much potential
confusion. Kind of like the word *interface* in that respect. Though
this choice would have no bad effect on core guys such as Berin, Leos or
Peters, may or may not present an un-necessary obstacle (?) to the
outside world coming in.
If there was a better choice available, that might be worth considering.
On an unrelated note, it has been fascinating watching the back and
forth here lately. Leaves no doubt that Avalon is being developed with
much care and attention to detail.
</delurk>
<lurk/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Torsten Curdt <tc...@dff.st>.
On Monday 17 June 2002 11:36, Peter Donald wrote:
> At 11:37 AM 6/17/2002 +0200, you wrote:
> >having the exception carrie the failed role would be elegant IMHO:
> >
> > try {
> > componentA = (A) cm.lookup(A.ROLE);
> > componentB = (B) cm.lookup(B.ROLE);
> > } catch (ComponentException e) {
> > throw new CascadingException("Could not find " + e.getRole(), e);
> > }
>
> Thats a kool idea - wanna send a patch ? :)
Sure ..if noone objects :-)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 11:37 AM 6/17/2002 +0200, you wrote:
> >having the exception carrie the failed role would be elegant IMHO:
> >
> > try {
> > componentA = (A) cm.lookup(A.ROLE);
> > componentB = (B) cm.lookup(B.ROLE);
> > } catch (ComponentException e) {
> > throw new CascadingException("Could not find " + e.getRole(), e);
> > }
>
> Thats a kool idea - wanna send a patch ? :)
I agree totally. That's a very cool idea.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 11:37 AM 6/17/2002 +0200, you wrote:
>having the exception carrie the failed role would be elegant IMHO:
>
> try {
> componentA = (A) cm.lookup(A.ROLE);
> componentB = (B) cm.lookup(B.ROLE);
> } catch (ComponentException e) {
> throw new CascadingException("Could not find " + e.getRole(), e);
> }
Thats a kool idea - wanna send a patch ? :)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Torsten Curdt <tc...@dff.st>.
On Sunday 16 June 2002 21:34, Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
> > I have to confess that I'm way over on Nicola's side here. The Avlon
> > framework CascadingException model enables a consitent approach to
> > handling of causal information that is really valuable.
> >
> > There may be a perfrmace penalty to the following - but for me its well
> > and truly justified:
> >
> > try
> > {
> > doSomething()
> > }
> > catch( Throwable e )
> > {
> > throw new CascadingException( "It didn't work.", e );
> > }
> >
> > The impact of the above is that I don't need logging statements in the
> > catch because the full information is pased back to the caller.
>
> Here,
>
> try {
> componentA = (A) cm.lookup(A.ROLE);
> componentB = (B) cm.lookup(B.ROLE);
> } catch (Exception e) {
> throw new CascadingException("It didn't work", e);
> }
>
> the only way to find out which component didn't make it to:
>
> 1) parse the stacktrace
> 2) get the offending line number
> 3) parse the source file (which might not even be there)
> 4) obtain the offending line
> 5) parse the line to obtain the component.
>
> result: no way. You have encapsulate each lookup in a try/catch if you
> want to have this granularity.
>
> This said, I think the exists() method solves many issues I have with
> this exception throwing verbosity overhead.
having the exception carrie the failed role would be elegant IMHO:
try {
componentA = (A) cm.lookup(A.ROLE);
componentB = (B) cm.lookup(B.ROLE);
} catch (ComponentException e) {
throw new CascadingException("Could not find " + e.getRole(), e);
}
my 2 cents
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 09:34 PM 6/16/2002 +0200, you wrote:
>What bugs me about Avalon is that it throws exception even if there is
>no exception at all.
>
>If a component I'm looking for is not found, this is an exception.
Thats why there is the hasComponent() method - why not use that? ;)
>If a parameter/configuration I'm looking for is not found, this is
>another exception.
Thats why you can pass defaults in (which means exceptions only thrown on
format violations).
>I simply disagree with the general concept of those being exceptions:
>they are just part of the rule, as anything else in my flow. I just
>wanted to know if they existed, to do something else.
This is possible but you haven't taken advantage of it - what exactly is
the problem with using this as it stands.
>But since there is a plan for an exists() method that allows me to get
>information on the environment without being forced to implement a
>try/catch around every method, I think we reached an acceptable
>compromise.
This feature has existed in avalon for a long time as hasComponent() instead.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Stephen McConnell wrote:
> >
> > I have to confess that I'm way over on Nicola's side here.
> The Avlon
> > framework CascadingException model enables a consitent approach to
> > handling of causal information that is really valuable.
> >
> > There may be a perfrmace penalty to the following - but for me its
> > well and truly justified:
> >
> > try
> > {
> > doSomething()
> > }
> > catch( Throwable e )
> > {
> > throw new CascadingException( "It didn't work.", e );
> > }
> >
> > The impact of the above is that I don't need logging
> statements in the
> > catch because the full information is pased back to the caller.
>
> Here,
>
> try {
> componentA = (A) cm.lookup(A.ROLE);
> componentB = (B) cm.lookup(B.ROLE);
> } catch (Exception e) {
> throw new CascadingException("It didn't work", e);
> }
>
> the only way to find out which component didn't make it to:
>
> 1) parse the stacktrace
> 2) get the offending line number
> 3) parse the source file (which might not even be there)
> 4) obtain the offending line
> 5) parse the line to obtain the component.
>
> result: no way. You have encapsulate each lookup in a
> try/catch if you want to have this granularity.
>
> This said, I think the exists() method solves many issues I
> have with this exception throwing verbosity overhead.
There is also the idea of changing the Exception we
use...
ComponentException
{
Throwable getThrowable(); // for cascading
String getRole(); // for determining which component
// we failed on...
}
There is more than one way to skin a cat.
The exists() is necessary for optional dependencies,
so it needs to stay no matter how you slice it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Stefano Mazzocchi wrote:
>Stephen McConnell wrote:
>
>
>>I have to confess that I'm way over on Nicola's side here. The Avlon
>>framework CascadingException model enables a consitent approach to
>>handling of causal information that is really valuable.
>>
>>There may be a perfrmace penalty to the following - but for me its well
>>and truly justified:
>>
>> try
>> {
>> doSomething()
>> }
>> catch( Throwable e )
>> {
>> throw new CascadingException( "It didn't work.", e );
>> }
>>
>>The impact of the above is that I don't need logging statements in the
>>catch because the full information is pased back to the caller.
>>
>>
>
>Here,
>
> try {
> componentA = (A) cm.lookup(A.ROLE);
> componentB = (B) cm.lookup(B.ROLE);
> } catch (Exception e) {
> throw new CascadingException("It didn't work", e);
> }
>
>the only way to find out which component didn't make it to:
>
> 1) parse the stacktrace
> 2) get the offending line number
> 3) parse the source file (which might not even be there)
> 4) obtain the offending line
> 5) parse the line to obtain the component.
>
>result: no way. You have encapsulate each lookup in a try/catch if you
>want to have this granularity.
>
I was actually not describing management of CM exceptions. If I want to
know if a component exists or not (as Pete has already noted) there is a
method "hasComponent" (and the equivalent hasService in SM) that lets
you do this. Knowing if a component is available is a non-issue.
However, if a component declares a dependency one a service/component
and its not provided - that's an exception condition because the
container is failing to live up to its end of the contract.
>
>
>What bugs me about Avalon is that it throws exception even if there is
>no exception at all.
>
I have the impression that you were not aware of the
hasComponent/hasService methods (also, see ablove note ono the condition
when non-supply of a compoennt is an exception).
>If a parameter/configuration I'm looking for is not found, this is
>another exception.
>
>I simply disagree with the general concept of those being exceptions:
>they are just part of the rule, as anything else in my flow. I just
>wanted to know if they existed, to do something else.
>
>
My impression is that the framework is really consistent in this
respect. If a have an application context in which I'm loking up a
"maybe-available-component-as-in-Cocoon-context" I can use hasComponet
but if I'm loking up something contractual then I'll be throwing an
exception. In the configuration stuff its the same -
config.getChild("fred").getAtrtribute("xxx") throws an exception if its
not found - but invoking config.getChild("fred").getAtrtribute("xxx",
null ) does not throw an exception. You use the appropriate methods for
the context your in.
>
>
>Is the component that throws the exception if it cannot find a suitable
>environment to run in, but exceptions should *NEVER* be used to obtain
>information on something, and unfortunately, Avalon forces you to do
>this even if you don't want to and I don't like this.
>
Totally disagreeon this assertion.
Can you give me an example ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
> I have to confess that I'm way over on Nicola's side here. The Avlon
> framework CascadingException model enables a consitent approach to
> handling of causal information that is really valuable.
>
> There may be a perfrmace penalty to the following - but for me its well
> and truly justified:
>
> try
> {
> doSomething()
> }
> catch( Throwable e )
> {
> throw new CascadingException( "It didn't work.", e );
> }
>
> The impact of the above is that I don't need logging statements in the
> catch because the full information is pased back to the caller.
Here,
try {
componentA = (A) cm.lookup(A.ROLE);
componentB = (B) cm.lookup(B.ROLE);
} catch (Exception e) {
throw new CascadingException("It didn't work", e);
}
the only way to find out which component didn't make it to:
1) parse the stacktrace
2) get the offending line number
3) parse the source file (which might not even be there)
4) obtain the offending line
5) parse the line to obtain the component.
result: no way. You have encapsulate each lookup in a try/catch if you
want to have this granularity.
This said, I think the exists() method solves many issues I have with
this exception throwing verbosity overhead.
> Somewhere possibly very high up in the chain, a error is generated in a
> logging file with a complete description based on the collection of
> causal information.
Hmmm, you seem to imply that componentization is an action that happens
only at some predefined stages. This is *absolutely* not the case and
must not be assumed.
> Seconldy, declaration at the interface level that
> an exception is as potential is necessary when your dealing with
> different people components.
Sorry, can't parse this one.
> If is a custom container handling specific
> components then the scope of the issue is scalled down - but at the
> abstract framework level - exceptions are possible and the more that is
> declared and forced to be managed the better.
Look, I'm not saying that Exceptions are bad, rather the opposite, it's
one great feature of Java, one the best. And I hate NPE like all of you
and blah blah.
*BUT*, exceptions are exactly what they are "exception to the rule",
something that you safely assume not to go wrong, until it does, but in
that case, you have some code that handles the situation.
What bugs me about Avalon is that it throws exception even if there is
no exception at all.
If a component I'm looking for is not found, this is an exception.
If a parameter/configuration I'm looking for is not found, this is
another exception.
I simply disagree with the general concept of those being exceptions:
they are just part of the rule, as anything else in my flow. I just
wanted to know if they existed, to do something else.
In the case of blocks, I agree: missing a block is clearly an exception,
an indication that something bad went wrong.
But for general components, this cannot be estimated since I might use
lookup (component, parameters, configurations) to understand my
environment and simply change behavior.
Is the component that throws the exception if it cannot find a suitable
environment to run in, but exceptions should *NEVER* be used to obtain
information on something, and unfortunately, Avalon forces you to do
this even if you don't want to and I don't like this.
But since there is a plan for an exists() method that allows me to get
information on the environment without being forced to implement a
try/catch around every method, I think we reached an acceptable
compromise.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
I have to confess that I'm way over on Nicola's side here. The Avlon
framework CascadingException model enables a consitent approach to
handling of causal information that is really valuable.
There may be a perfrmace penalty to the following - but for me its well
and truly justified:
try
{
doSomething()
}
catch( Throwable e )
{
throw new CascadingException( "It didn't work.", e );
}
The impact of the above is that I don't need logging statements in the
catch because the full information is pased back to the caller.
Somewhere possibly very high up in the chain, a error is generated in a
logging file with a complete description based on the collection of
causal information. Seconldy, declaration at the interface level that
an exception is as potential is necessary when your dealing with
different people components. If is a custom container handling specific
components then the scope of the issue is scalled down - but at the
abstract framework level - exceptions are possible and the more that is
declared and forced to be managed the better.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Leo Simons wrote:
>
>
>>>I also question that it results in more performant code, as you
>>>do not pay for exceptions unless they are thrown (See
>>>http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
>>>for exception handling.)
>>
>>so I thought originally. Stefano suggested differently though. Stefano?
>
>
> No, this is correct. Exceptions-wrapped lookups irritate me for the
> performance penalty
Premature optimization is the root of all evil.
> of lookup failure *and* for the verbosity penalty in
> code.
get, set, ...
Wanna use lisp?
Java *is* verbose, but it's part of the semantics in this case.
> For example, try/catch was designed to allow more stuff to be included
> in a single try/catch, this covers for many different errors of the same
> kind. So
>
> try {
> ... [a bunch of code] ...
> } catch (A a) {
> ...
> } catch (B b) {
> ...
> } catch (C c) {
> ...
> } catch (D c) {
> ...
> } finally {
> ...
> }
>
> this is a declarative way to associate specific behavior on the errors
> that emerge on a code that is *assumed* to work correctly.
>
> In Avalon, the granularity of the exception is too low, forcing you to
> have a single try/catch on every component, in order to provide
> meaningful error messages. Sure, you could do:
>
> try {
> ...[ a bunch of lookups ]...
> } catch (ComponentNotFoundException e) {
> ...
> }
>
> but the error message
>
> Sorry, can't find a component.
>
> will irritate me even more. (note that the exception originating line is
> lost on stacktrace exceptions (which is a big design mistake for java,
> IMO)).
Which we should take care to avoid, of course, properly cascading.
> So you do
>
> try {
> parser = (Parser) cm.lookup(Parser.ROLE);
> } catch (ComponentNotFoundException e) {
> log("can't find parser");
> }
>
> and so on. If you look in Cocoon we have several hundreds of examples of
> this. Now, with exists, you can do:
>
> if (cm.exists(parser)) parser = (Parser) cm.lookup(Parser.ROLE)
> else log ("can't find parser);
>
> which could be equally verbose if written like
>
> if (cm.exists(parser)) {
> parser = (Parser) cm.lookup(Parser.ROLE);
> } else {
> log ("can't find parser");
> }
>
> but the difference is that if I'm *POSITIVE* that the component already
> exists (otherwise, I couldn't possibly reach this point in code! we have
> tons of examples of this in Cocoon), I don't care and go directly on
>
> parser = (Parser) cm.lookup(parser);
>
> Now, if we make 'ComponentNotFoundException' extend RunTimeException,
> then we could be back-compatible with the try/catch style failure, but
> without *FORCING* people to do it, if they don't want and know what they
> are doing.
If people would always know what they are doing, we would have pointer
arithmetic in Java.
The point is, believe me, that in some things, see exception handling
and build systems, programmers simply don't care much.
As Avalon forces, or at leat tries to force, IoC with interfaces and
lifecycle, we should not run away from doing it with exceptions.
You have SoC bells ringing, I have my exception handling bells going
WILD now :-O ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> No, this is correct. Exceptions-wrapped lookups irritate me for the
> performance penalty of lookup failure
I share that concern. If it is expected for lookups to fail, and this
happens in a piece of code that affects performance, that's annoying.
> *and* for the verbosity penalty in
> code.
This one, I do not. Java is a verbose language; exceptions are the
language construct you will have to live with.
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> > I also question that it results in more performant code, as you
> > do not pay for exceptions unless they are thrown (See
> > http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
> > for exception handling.)
>
> so I thought originally. Stefano suggested differently though. Stefano?
No, this is correct. Exceptions-wrapped lookups irritate me for the
performance penalty of lookup failure *and* for the verbosity penalty in
code.
For example, try/catch was designed to allow more stuff to be included
in a single try/catch, this covers for many different errors of the same
kind. So
try {
... [a bunch of code] ...
} catch (A a) {
...
} catch (B b) {
...
} catch (C c) {
...
} catch (D c) {
...
} finally {
...
}
this is a declarative way to associate specific behavior on the errors
that emerge on a code that is *assumed* to work correctly.
In Avalon, the granularity of the exception is too low, forcing you to
have a single try/catch on every component, in order to provide
meaningful error messages. Sure, you could do:
try {
...[ a bunch of lookups ]...
} catch (ComponentNotFoundException e) {
...
}
but the error message
Sorry, can't find a component.
will irritate me even more. (note that the exception originating line is
lost on stacktrace exceptions (which is a big design mistake for java,
IMO)).
So you do
try {
parser = (Parser) cm.lookup(Parser.ROLE);
} catch (ComponentNotFoundException e) {
log("can't find parser");
}
and so on. If you look in Cocoon we have several hundreds of examples of
this. Now, with exists, you can do:
if (cm.exists(parser)) parser = (Parser) cm.lookup(Parser.ROLE)
else log ("can't find parser);
which could be equally verbose if written like
if (cm.exists(parser)) {
parser = (Parser) cm.lookup(Parser.ROLE);
} else {
log ("can't find parser");
}
but the difference is that if I'm *POSITIVE* that the component already
exists (otherwise, I couldn't possibly reach this point in code! we have
tons of examples of this in Cocoon), I don't care and go directly on
parser = (Parser) cm.lookup(parser);
Now, if we make 'ComponentNotFoundException' extend RunTimeException,
then we could be back-compatible with the try/catch style failure, but
without *FORCING* people to do it, if they don't want and know what they
are doing.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> It is so funny to see one arguing for exceptions in one
> place, then against them in another (and vice versa).
>
Throwing Exceptions for exceptional circumstances?
> > > > Also, with just String hints, if you use a ServletRequest
> > > as hint, you
> > > > end up with:
> > > >
> > > > lookup (role, stringifyRequest (request))
> > >
> > > yes. Keeping the interface more simple/limited means that
> > > complex use of the interface becomes more complex. This is a
> > > choice; I'm all for keeping the CM simple. For complex uses,
> > > there's JNDI, DAP, etc etc.
> >
> > I'm against it. If the framework is intended to make writing of
> > containers easy - then I'd be with you. But when you can
> get complex
> > use by the client as cheaply as this, then I think it makes
> sense to
> > put it in. Complexity should, when possible, be moved from
> the client
> > and into the framework - after all, using the framework to
> reduce the
> > complexity in our own code is what this is all about, right?
>
> good point. But still
>
> lookupFunction( String e, Object key ) seems too complex. It
> doesn't resemble a Map enough. What is it internally,
> conceptually? A two-dimensional hash? Why does a directory
> need a two-dimensional hash? I can see one-dimensional, and
> n-dimensional. I don't get the two-dimensional.
It's not 2D - it is n-D. The Object may be anything - a Map or
whatever. The reason I want String,Object is because we have
fixed one dimension to be an interface name. If we hadn't,
a lookup(Object) would do.
> > > Which of these is most desirable, when that which you are
> > > looking up is _not_ guaranteed to exist?
> >
> > The exist() way of doing things. But the overwhelming use
> case is for
> > composers to directly call lookup() for components they *need* as
> > opposed to components that are optional - in which case they use if
> > (hasComponent()) lookup(). And thus the Exception way of
> doing things
> > is better.
>
> Uh, I'm thinking the reverse: the overwhelming use case is
> for composer to call lookup() for components they need, so
> they specify to the container that these are required and the
> container guarantees they're there or doesn't call compose()
> - so they do *not* use exists() there. Where the component
> can be optionally present, its existence is not guaranteed by
> contract.
That's what I meant, but maybe not what I wrote.
> > > if the lookup should never fail, neither if(exists()) nor
> > > try{}/catch{}/finally{} should be necessary at all.
> >
> > *should* as opposed to *could*! A lookup failing is an exceptional
> > case, and should be treated as such.
>
> But when the container guarantees "if you configure me
> correctly, the lookup will never fail", why should the
> component developer still check?
Because you get an instant ComponentException instead of a
NullPointerException later in the processing.
> > Since you are removing functionality from the CM, I want to know
> > whether you are removing it from the system completely, or if an
> > equivalent to release() will exist, just in another form.
>
> I thought we'd keep these issues separate (and separate
> proposals), as that is what they should be.
No. If you want to replace something that does A, B and C,
with something that only does A and B, you have to explain
how to do C or how you solve the problem that C was intended to
solve.
And you don't. Peter doesn't, and Berin doesn't either. Just a fond
hope that it is possible - but is it really, under the constraints
imposed by your proposed interface?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > > All ComponentManagers should support hints, or none. We're
> > not making
> > > the developers any favors by introducing yet another "this should
> > > work, but then again it might not".
> >
> > I think it would be relatively simple to explain which
> > Containers make use of a ComponentManager that supports
> > hints, and which do not. ie "if you use hints, you can use
> > fortress but not phoenix".
> >
> > So what you say is "this works in this setup, but not in this one".
> >
> > Note that if the contract for hints says that the CM can
> > freely ignore them (as Berin proposes), that is a lot more
> > like "this should have an effect, but then again it might not".
>
> That's fine. If lookup(role,hint) -> lookup(role) in Phoenix, then
> that's fine. I think it limits the number of components that can
> work in Phoenix, but that's an issue with Phoenix. I just do not
> want an IllegalArgumentException back.
'kay. I'll be happy to keep disagreeing and not specify the exception (I
can still throw it in private =).
It is so funny to see one arguing for exceptions in one place, then
against them in another (and vice versa).
> > > Also, with just String hints, if you use a ServletRequest
> > as hint, you
> > > end up with:
> > >
> > > lookup (role, stringifyRequest (request))
> >
> > yes. Keeping the interface more simple/limited means that
> > complex use of the interface becomes more complex. This is a
> > choice; I'm all for keeping the CM simple. For complex uses,
> > there's JNDI, DAP, etc etc.
>
> I'm against it. If the framework is intended to make writing of
> containers easy - then I'd be with you. But when you can get
> complex use by the client as cheaply as this, then I think it
> makes sense to put it in. Complexity should, when possible, be moved
> from the client and into the framework - after all, using the
> framework to reduce the complexity in our own code is what this
> is all about, right?
good point. But still
lookupFunction( String e, Object key ) seems too complex. It doesn't
resemble a Map enough. What is it internally, conceptually? A
two-dimensional hash? Why does a directory need a two-dimensional hash?
I can see one-dimensional, and n-dimensional. I don't get the
two-dimensional.
> > Which of these is most desirable, when that which you are
> > looking up is _not_ guaranteed to exist?
>
> The exist() way of doing things. But the overwhelming use case is for
> composers to directly call lookup() for components they *need* as
> opposed to components that are optional - in which case they use
> if (hasComponent()) lookup(). And thus the Exception way of doing
> things is better.
Uh, I'm thinking the reverse: the overwhelming use case is for composer
to call lookup() for components they need, so they specify to the
container that these are required and the container guarantees they're
there or doesn't call compose() - so they do *not* use exists() there.
Where the component can be optionally present, its existence is not
guaranteed by contract.
> > if the lookup should never fail, neither if(exists()) nor
> > try{}/catch{}/finally{} should be necessary at all.
>
> *should* as opposed to *could*! A lookup failing is an exceptional
> case, and should be treated as such.
But when the container guarantees "if you configure me correctly, the
lookup will never fail", why should the component developer still check?
> > on the subject of release(): if a proposal for the CM needs
> > to include a proposal regarding resource management (as you
> > state), then you disagree with the statement that resource
> > management is not of concern to the CM?
>
> Since you are removing functionality from the CM, I want to know
> whether you are removing it from the system completely, or if
> an equivalent to release() will exist, just in another form.
I thought we'd keep these issues separate (and separate proposals), as
that is what they should be.
Anyway, I think the way forward here is for a pool to implement the same
interface as the component it pools, or be cast to the same role. ie the
XXXXManager setup discussed.
This can be optional though and does not need to be part of the core of
all cores -- the lifecycle contracts.
cheers,
- LSD (That Other Leo)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 09:42 PM 6/16/2002 +0200, you wrote:
> > It is a design choice cocoon has made in the context of a specific
> > container.
>
>No, we were simply forced to use this because Avalon didn't provide us
>any other way to obtain information on the lookup environment without
>trying to access the component and failing (AFAIK, I didn't wrote that
>code)
Have a look at code to COmponentManager - has been possible for ages. )
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 05:26 AM 6/21/2002 -0400, you wrote:
> > > ComponentException is a
> > > system exception not an application system and should be handled by the
> > > container not by individual component. Receiving a ComponentException
> > > should mean that the whole component is fubared.
> >
> > I simply disagree on the concept, but it doesn't matter as long as there
> > is a way to ask to the container if a component is present in the system
> > without having to catch an exception.
>
>I'm a non-committer and a total Avalon newbie, but I just can't resist.
>In the olden days (read: C programming), it would be OBVIOUS that you
>would do
>
> Component c = container.lookup(name);
> if (c == null)
> // not found
> else
> // found
>
>I know having the exists() method achieves the same, but any sane
>programmer would retch at the idea of doing TWO searches, one to
>ensure the component is there, one to retrieve it.
Well the "search" should be just a lookup in a table using a simple hashing
algo. So exists() should be relatively cost free. lookup() may be expensive
(due to instantiation costs or whatever) or it could be also lightweight.
> There, I said it. Perhaps this doesn't apply in the Avalon world, but
>I fail to see why lookup() couldn't just simply return the component
>when it is found, or null in any other case.
Unfortunately that style of development tends to hide bugs. The reasoning
for it is the same reasoning why java moved from using return codes to
indicate errors to using exceptions to indicate errors. It is expected that
you should never use lookup() unless you know the component is present.
Mostly style for safety ... I started out hating but then learnt to live
with it and now I think it is all good ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Gonzalo A. Diethelm wrote:
>>>ComponentException is a
>>>system exception not an application system and should be handled by the
>>>container not by individual component. Receiving a ComponentException
>>>should mean that the whole component is fubared.
>>>
>>>
>>I simply disagree on the concept, but it doesn't matter as long as there
>>is a way to ask to the container if a component is present in the system
>>without having to catch an exception.
>>
>>
>
>I'm a non-committer and a total Avalon newbie, but I just can't resist.
>In the olden days (read: C programming), it would be OBVIOUS that you
>would do
>
> Component c = container.lookup(name);
> if (c == null)
> // not found
> else
> // found
>
>I know having the exists() method achieves the same, but any sane
>programmer would retch at the idea of doing TWO searches, one to
>ensure the component is there, one to retrieve it.
>
>There, I said it. Perhaps this doesn't apply in the Avalon world, but
>I fail to see why lookup() couldn't just simply return the component
>when it is found, or null in any other case.
>
Something to consider is that an exist operation can be interprited as
"tell me if it is possible to return a service corresponding to profile
I'm providing". This allows a type based response by a container -
because the container knows if the service type is valid, and if the
assembly constraints are valid, and as such, it knows if it is possible
or not without actually instantiating the service. This means that the
instantiation arrising from a lookup invocation can be deferred until
such time that the service is actually needed (if at all), resulting in
reduced memory footprint and faster component initialization times.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > ComponentException is a
> > system exception not an application system and should be handled by the
> > container not by individual component. Receiving a ComponentException
> > should mean that the whole component is fubared.
>
> I simply disagree on the concept, but it doesn't matter as long as there
> is a way to ask to the container if a component is present in the system
> without having to catch an exception.
I'm a non-committer and a total Avalon newbie, but I just can't resist.
In the olden days (read: C programming), it would be OBVIOUS that you
would do
Component c = container.lookup(name);
if (c == null)
// not found
else
// found
I know having the exists() method achieves the same, but any sane
programmer would retch at the idea of doing TWO searches, one to
ensure the component is there, one to retrieve it.
There, I said it. Perhaps this doesn't apply in the Avalon world, but
I fail to see why lookup() couldn't just simply return the component
when it is found, or null in any other case.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 04:11 PM 6/14/2002 +0200, you wrote:
> >Leo Sutic wrote:
> >
> > > A lookup failing is an exceptional
> > > case, and should be treated as such.
> >
> >I think this is the key issuse here.
> >
> >Example, I might change the behavior of a component, if another
> >component it requires is missing (this happens in Cocoon a lot)
> >
> >This is *not* an exceptional case, but a straightforward programming
> >flow.
>
> It is a design choice cocoon has made in the context of a specific
> container.
No, we were simply forced to use this because Avalon didn't provide us
any other way to obtain information on the lookup environment without
trying to access the component and failing (AFAIK, I didn't wrote that
code)
> You could quite easily use "boolean hasComponent(String)" to
> check before doing a lookup.
I agree.
> A lot of the problems in cocoon relate to the
> fact that there is a merging of concepts between Container and
> ComponentManager.
I agree with you here. I'm complaining about Avalon design decisions,
but I might as well be complaining about Cocoon design decisions :)
> In reality the container should map from application
> namespace into component namespace and components should only access
> component namespace. If you do that and then use hasComponent() method then
> most (all?) of this ugly code disapears. I believe thats what Leo wants to
> do with Fortress.
I think the proposed exist() methods will solve the issue, yes.
> ie You desiigned your system to work this way.
Ehm, I designed most of the Cocoon2 architectural concepts, but most of
the actual code (even in core) was written by others. I'd be surprised
to see how little is the percentage of code I wrote in Cocoon :)
> ComponentException is a
> system exception not an application system and should be handled by the
> container not by individual component. Receiving a ComponentException
> should mean that the whole component is fubared.
I simply disagree on the concept, but it doesn't matter as long as there
is a way to ask to the container if a component is present in the system
without having to catch an exception.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 04:11 PM 6/14/2002 +0200, you wrote:
>Leo Sutic wrote:
>
> > A lookup failing is an exceptional
> > case, and should be treated as such.
>
>I think this is the key issuse here.
>
>Example, I might change the behavior of a component, if another
>component it requires is missing (this happens in Cocoon a lot)
>
>This is *not* an exceptional case, but a straightforward programming
>flow.
It is a design choice cocoon has made in the context of a specific
container. You could quite easily use "boolean hasComponent(String)" to
check before doing a lookup. A lot of the problems in cocoon relate to the
fact that there is a merging of concepts between Container and
ComponentManager. In reality the container should map from application
namespace into component namespace and components should only access
component namespace. If you do that and then use hasComponent() method then
most (all?) of this ugly code disapears. I believe thats what Leo wants to
do with Fortress.
ie You desiigned your system to work this way. ComponentException is a
system exception not an application system and should be handled by the
container not by individual component. Receiving a ComponentException
should mean that the whole component is fubared.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Leo Sutic wrote:
>
>
>>A lookup failing is an exceptional
>>case, and should be treated as such.
>
>
> I think this is the key issuse here.
>
> Example, I might change the behavior of a component, if another
> component it requires is missing (this happens in Cocoon a lot)
>
> This is *not* an exceptional case, but a straightforward programming
> flow.
>
> Making the exceptions thrown a RuntimeException allows people that
> consider lookups an exceptional case to use try/catch and those who use
> it as a programming flow, to use normal method calls (or ignore the
> exists() alltogether)
*ALL* Runtime exceptions go unnoticed to programmers.
Give me three programmers that check that a class throws
RuntimeExceptions; I know none.
> As for the argument that try/catch enforce good programming practices, I
> can point you to a bunch of
>
> try {
> ...
> } catch (Exception e) {}
>
> examples even in high-quality code that show you this is *NOT* the case:
> you can't force programmers to be smart, but you can give them tools
> that match their differences.
But you can make them take a decision.
With try-catch they at least need to know that there is something to catch.
With Runtime ones, nobody would know, even the programmers that use
try-catch the correct way.
Let me give you a concrete example: Cocoon exceptions.
Cocoon used many RuntimeException, also in the XSLT components, and many
of them were really difficult to track down.
With RuntimeExceptions, you are taking the compulsory responsibility of
handling them away from the method caller.
I am *strongly* against RuntimeExceptions, having been burnt many and
many times because of them.
What is the most common exception that one gets that basically has no
meaning, is hard to track down and is never handled:
java.lang.NullPointerException, which is a java.lang.RuntimeException.
You want Avalon to throw "NullPointerExceptions" ?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-06-17 at 11:35, Peter Donald wrote:
> At 11:24 AM 6/17/2002 +0200, you wrote:
> >note: renamed exists() to contains() to follow java.util convention
>
> should be hasComponent(String) as that already exists in A4 ComponentManager.
yup.
> >while some of us may feel that the use of hints is a bad idea, making an
> >allowance for them will ease upgrade from A4 to A5.
>
> If roles exist in A5 there will not be any A5. Theres no point in
> "upgrading" to another version of framework if it forces developers to
> scatter metainfo about in code and outside code.
you mean hints :) I agree with you that hints are not a good idea, but I
have less of a problem if they are declared optional (the developer
won't be forced to do anything). They'll just die out eventually.
> >Similarly, while
> >some of us may feel that a component should not find out about its
> >environment through the ComponentManager interface, a contains() method
> >is trivial to implement and does no big conceptual harm.
>
> No one seems to notice when I say this is already possible and has been for
> a very very very very long time.
but there were some objections to it during this discussion.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 11:24 AM 6/17/2002 +0200, you wrote:
>note: renamed exists() to contains() to follow java.util convention
should be hasComponent(String) as that already exists in A4 ComponentManager.
>while some of us may feel that the use of hints is a bad idea, making an
>allowance for them will ease upgrade from A4 to A5.
If roles exist in A5 there will not be any A5. Theres no point in
"upgrading" to another version of framework if it forces developers to
scatter metainfo about in code and outside code.
>Similarly, while
>some of us may feel that a component should not find out about its
>environment through the ComponentManager interface, a contains() method
>is trivial to implement and does no big conceptual harm.
No one seems to notice when I say this is already possible and has been for
a very very very very long time.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
On Sun, 2002-06-16 at 22:00, Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
> All right. I'm convinced that as long as we have an
> exist(role)/exist(role,hint) method I'm fine with keeping the exception.
so we're at:
/**
* A ComponentManager is a simple lookup mechanism for
* {@see $Components Components}. The lookup key is a {@see $Role role},
* possibly with a hint to further specify the lookup. Support for hints
* in ComponentManager implementations is optional; you cannot depend on
* the hint being taken into account.
*
* <p>Typical usage:</p>
*
* <pre>
* // inside your Component...
* compose( ComponentManager cm ) throws ComponentException
* {
* // you don't have to catch the ComponentException if you
* // don't want to; the container will handle it.
* if( cm.exists( MyComponent.ROLE ) )
* m_myComponent = cm.lookup( MyComponent.ROLE );
*
* // more simple (no-hint) lookups here.
*
* if( cm.exists( AnotherComponent.ROLE,
* AnotherComponent.SOME_HINT ) )
* m_anotherComponent = cm.lookup( AnotherComponent.ROLE,
* AnotherComponent.SOME_HINT );
* }
* // ...
* </pre>
*/
interface ComponentManager
{
/**
* Look up a component.
*
* @throws ComponentException if there is no component
* inside the ComponentManager implementing the specified role.
*/
Object lookup( String role ) throws ComponentException;
/**
* Look up a component.
*
* @throws ComponentException if there is no component
* inside the ComponentManager implementing the specified role.
*/
Object lookup( String role, String hint )
throws ComponentException;
/**
* Determine whether the ComponentManager contains a component
* with the specified role.
*/
boolean contains( String role );
/**
* Determine whether the ComponentManager contains a component
* with the specified role and hint. Will always return false if
* the ComponentManager does not support hints.
*/
boolean contains( String role, String hint );
}
note: renamed exists() to contains() to follow java.util convention
while some of us may feel that the use of hints is a bad idea, making an
allowance for them will ease upgrade from A4 to A5. Similarly, while
some of us may feel that a component should not find out about its
environment through the ComponentManager interface, a contains() method
is trivial to implement and does no big conceptual harm.
regards,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
> Leo Sutic wrote:
>
> >>From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >>
> >>Leo Sutic wrote:
> >>
> >>
> >>
> >>>A lookup failing is an exceptional
> >>>case, and should be treated as such.
> >>>
> >>>
> >>I think this is the key issuse here.
> >>
> >>Example, I might change the behavior of a component, if
> >>another component it requires is missing (this happens in
> >>Cocoon a lot)
> >>
> >>This is *not* an exceptional case, but a straightforward
> >>programming flow.
> >>
> >>
> >
> >Stefano,
> >
> >what you are saying is that breaking one component's dependencies
> >is not exceptional. I say it is. Whether that is exceptional in the
> >context of the whole application (i.e. Cocoon tries to start all
> >components and just lets some of them explode due to failed
> >dependencies) is not the issue here - for the individual component
> >it is *very* exceptional that the contract between it and the container
> >has been broken (not all dependencies exist).
> >
>
> ++1
All right. I'm convinced that as long as we have an
exist(role)/exist(role,hint) method I'm fine with keeping the exception.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>>Leo Sutic wrote:
>>
>>
>>
>>>A lookup failing is an exceptional
>>>case, and should be treated as such.
>>>
>>>
>>I think this is the key issuse here.
>>
>>Example, I might change the behavior of a component, if
>>another component it requires is missing (this happens in
>>Cocoon a lot)
>>
>>This is *not* an exceptional case, but a straightforward
>>programming flow.
>>
>>
>
>Stefano,
>
>what you are saying is that breaking one component's dependencies
>is not exceptional. I say it is. Whether that is exceptional in the
>context of the whole application (i.e. Cocoon tries to start all
>components and just lets some of them explode due to failed
>dependencies) is not the issue here - for the individual component
>it is *very* exceptional that the contract between it and the container
>has been broken (not all dependencies exist).
>
++1
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Leo Sutic wrote:
>
> > A lookup failing is an exceptional
> > case, and should be treated as such.
>
> I think this is the key issuse here.
>
> Example, I might change the behavior of a component, if
> another component it requires is missing (this happens in
> Cocoon a lot)
>
> This is *not* an exceptional case, but a straightforward
> programming flow.
Stefano,
what you are saying is that breaking one component's dependencies
is not exceptional. I say it is. Whether that is exceptional in the
context of the whole application (i.e. Cocoon tries to start all
components and just lets some of them explode due to failed
dependencies) is not the issue here - for the individual component
it is *very* exceptional that the contract between it and the container
has been broken (not all dependencies exist).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
> A lookup failing is an exceptional
> case, and should be treated as such.
I think this is the key issuse here.
Example, I might change the behavior of a component, if another
component it requires is missing (this happens in Cocoon a lot)
This is *not* an exceptional case, but a straightforward programming
flow.
Making the exceptions thrown a RuntimeException allows people that
consider lookups an exceptional case to use try/catch and those who use
it as a programming flow, to use normal method calls (or ignore the
exists() alltogether)
As for the argument that try/catch enforce good programming practices, I
can point you to a bunch of
try {
...
} catch (Exception e) {}
examples even in high-quality code that show you this is *NOT* the case:
you can't force programmers to be smart, but you can give them tools
that match their differences.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > All ComponentManagers should support hints, or none. We're
> not making
> > the developers any favors by introducing yet another "this should
> > work, but then again it might not".
>
> I think it would be relatively simple to explain which
> Containers make use of a ComponentManager that supports
> hints, and which do not. ie "if you use hints, you can use
> fortress but not phoenix".
>
> So what you say is "this works in this setup, but not in this one".
>
> Note that if the contract for hints says that the CM can
> freely ignore them (as Berin proposes), that is a lot more
> like "this should have an effect, but then again it might not".
That's fine. If lookup(role,hint) -> lookup(role) in Phoenix, then
that's fine. I think it limits the number of components that can
work in Phoenix, but that's an issue with Phoenix. I just do not
want an IllegalArgumentException back.
> > Also, with just String hints, if you use a ServletRequest
> as hint, you
> > end up with:
> >
> > lookup (role, stringifyRequest (request))
>
> yes. Keeping the interface more simple/limited means that
> complex use of the interface becomes more complex. This is a
> choice; I'm all for keeping the CM simple. For complex uses,
> there's JNDI, DAP, etc etc.
I'm against it. If the framework is intended to make writing of
containers easy - then I'd be with you. But when you can get
complex use by the client as cheaply as this, then I think it
makes sense to put it in. Complexity should, when possible, be moved
from the client and into the framework - after all, using the
framework to reduce the complexity in our own code is what this
is all about, right?
> > I question the assertion
> > that the use of exists() as you propose is common java practice.
>
> java.lang.System returns null on a failed lookup
>
> java.util.Collection defines contains()
> java.awt.Container defines contains()
> java.util.Map defines containsKey() and returns null on a
> failed lookup
>
> java.lang.ClassLoader throws an exception on a failed lookup
> java.rmi.Registry throws an exception on a failed lookup
>
> javax.naming.Context defines no equavalent, but instead
> returns a new instance of itself on a failed lookup (not
> desirable behaviour!)
>
> Which of these is most desirable, when that which you are
> looking up is _not_ guaranteed to exist?
The exist() way of doing things. But the overwhelming use case is for
composers to directly call lookup() for components they *need* as
opposed to components that are optional - in which case they use
if (hasComponent()) lookup(). And thus the Exception way of doing
things is better.
> if the lookup should never fail, neither if(exists()) nor
> try{}/catch{}/finally{} should be necessary at all.
*should* as opposed to *could*! A lookup failing is an exceptional
case, and should be treated as such.
> there you go =)
>
> on the subject of release(): if a proposal for the CM needs
> to include a proposal regarding resource management (as you
> state), then you disagree with the statement that resource
> management is not of concern to the CM?
Since you are removing functionality from the CM, I want to know
whether you are removing it from the system completely, or if
an equivalent to release() will exist, just in another form.
I think this mail sums up my views on Berin's proposal:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102352975913660&w=2
and this is why I do not think GC will do as a release() mechanism:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102363047028722&w=2
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > - proposal for component management in avalon 5:
> > 1) removal of ComponentSelector
> > 2) removal of release()
>
> Without including in the proposal a replacement for CS when it
> operates on Objects (such as when selecting components based
> on a ServletRequest), and a replacement for release() that can
> handle switching between pooled and non-pooled components without
> any changes to the client code, I can not vote for this proposal.
>
> ------------------------
>
> All ComponentManagers should support hints, or none. We're not
> making the developers any favors by introducing yet another
> "this should work, but then again it might not".
I think it would be relatively simple to explain which Containers make
use of a ComponentManager that supports hints, and which do not. ie "if
you use hints, you can use fortress but not phoenix".
So what you say is "this works in this setup, but not in this one".
Note that if the contract for hints says that the CM can freely ignore
them (as Berin proposes), that is a lot more like "this should have an
effect, but then again it might not".
> Also, with just String hints, if you use a ServletRequest as
> hint, you end up with:
>
> lookup (role, stringifyRequest (request))
yes. Keeping the interface more simple/limited means that complex use of
the interface becomes more complex. This is a choice; I'm all for
keeping the CM simple. For complex uses, there's JNDI, DAP, etc etc.
> The
>
> if (exists (role)) manager.lookup (role)
>
> construct should only be required when the role you are looking
> up is optional.
agreed. Whether a role is optional is defined in the contract between
container and component (which may be configuration-dependent).
> I question the assertion
> that the use of exists() as you propose is common java practice.
java.lang.System returns null on a failed lookup
java.util.Collection defines contains()
java.awt.Container defines contains()
java.util.Map defines containsKey() and returns null on a failed lookup
java.lang.ClassLoader throws an exception on a failed lookup
java.rmi.Registry throws an exception on a failed lookup
javax.naming.Context defines no equavalent, but instead returns a new
instance of itself on a failed lookup (not desirable behaviour!)
Which of these is most desirable, when that which you are looking up is
_not_ guaranteed to exist?
// returning null on failure
if( null != (m_component = (MyComponent)cm.lookup( MyComponent.ROLE ))
m_component.doStuff();
else
whoops();
// use exists()
if( cm.exists( MyComponent.ROLE ) )
{
m_component = (MyComponent) cm.lookup( MyComponent.ROLE );
m_component.doStuff();
}
else
whoops();
// use exception
try
{
m_component = cm.lookup( MyComponent.ROLE );
}
catch( LookupException le )
{
whoops();
}
Which of these is most desirable, when what you are looking up _is_
guaranteed to exist?
// returning null on failure
m_component = (MyComponent)cm.lookup( MyComponent.ROLE );
m_component.doStuff();
// use exists()
m_component = (MyComponent) cm.lookup( MyComponent.ROLE );
m_component.doStuff();
// use exception
try
{
m_component = cm.lookup( MyComponent.ROLE );
}
catch( LookupException le )
{
// will never happen
}
Which case is more common?
> I also question that it results in more performant code, as you
> do not pay for exceptions unless they are thrown (See
> http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
> for exception handling.)
so I thought originally. Stefano suggested differently though. Stefano?
However, as the CM is likely to use a Map of some sort internally, there
will still be a check against null to be able to throw the exception,
within the CM:
lookup( Key ) throws ComponentException {
// ...
final Object result = m_map.lookup( Key );
if (result == null)
throw new ComponentException();
// ...
}
> - thus you have traded a lookup that
> should not fail except in exceptional circumstances for a check
> *and* a lookup.
if the lookup should never fail, neither if(exists()) nor
try{}/catch{}/finally{} should be necessary at all. If a container
guarantees that either everything specified as needed by a component
exists, or that compose() will not be called on the component, that is
your case.
If it does not, you need to check against null (or a method that returns
boolean), or catch exceptions.
> Please justify these assumptions.
there you go =)
on the subject of release(): if a proposal for the CM needs to include a
proposal regarding resource management (as you state), then you disagree
with the statement that resource management is not of concern to the CM?
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
which are suggestions, not required practice. We have decided it comes
in handy in 90% of applications that a role is closely coupled to the
interface name.
- LSD
> It is listed under "Naming Idioms":
> http://jakarta.apache.org/avalon/developing/framework.html
>
> /LS
>
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > Leo Sutic wrote:
> >
> > >
> > >The need for hints exist because we have decided that the
> > >role should be an interface name.
> > >
> >
> > Slowdown here - can anyone/someone please refer me to any Avalon
> > framework documentation anywhere that states a role is an interface
> > name? Please - let's not get mixed up between decisions
> > concerning ECM.
> > The CM/SM is not and does not inherit from ECM.
>
>
> --
> 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: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Sutic wrote:
>It is listed under "Naming Idioms":
>http://jakarta.apache.org/avalon/developing/framework.html
>
This isn't part of the contact of CM/SM. This is one approach to
leveraging the framework - an approach that happens to be very closely
related to the ECM which means the usage of the patterns that the above
document refers to. This is a discussion about A5 framework so lets
keep it focussed on the contractual defintion.
Cheers, Steve.
>
>/LS
>
>
>
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>
>>Leo Sutic wrote:
>>
>>
>>
>>>The need for hints exist because we have decided that the
>>>role should be an interface name.
>>>
>>>
>>>
>>Slowdown here - can anyone/someone please refer me to any Avalon
>>framework documentation anywhere that states a role is an interface
>>name? Please - let's not get mixed up between decisions
>>concerning ECM.
>> The CM/SM is not and does not inherit from ECM.
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
It is listed under "Naming Idioms":
http://jakarta.apache.org/avalon/developing/framework.html
/LS
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Leo Sutic wrote:
>
> >
> >The need for hints exist because we have decided that the
> >role should be an interface name.
> >
>
> Slowdown here - can anyone/someone please refer me to any Avalon
> framework documentation anywhere that states a role is an interface
> name? Please - let's not get mixed up between decisions
> concerning ECM.
> The CM/SM is not and does not inherit from ECM.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>
>>Berin Loritsch wrote:
>>
>>>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>>>
>>>>Leo Sutic wrote:
>>>>
>>>>>The need for hints exist because we have decided that the role should be an interface name.
>>>>>
>>>>>Slowdown here - can anyone/someone please refer me to any Avalon
>>>>>framework documentation anywhere that states a role is an interface
>>>>>name? Please - let's not get mixed up between decisions
>>>>>concerning ECM.
>>>>>The CM/SM is not and does not inherit from ECM.
>>>>>
>>>Developing with Avalon?
>>>
>>>It's a decision we came to a long time ago.
>>>
>>-1
>>
>>The "decision" is not documented in the CM/SM interfaces - is not
>>enforced by anything in the framework least of all
>>DefaultComponentManager or DefaultServiceManager. But the
>>worst thing of all is that implies the potential interpritation
>>of the lookup key on a CM/SM manager implemetation. The decision
>>I accept is the decision expressed by the CM/SM interfaces and the
>>javadoc that goes with them.
>>
>>Cheers, Steve.
>>
>
>Steve, with all do respect, I do not know what your "-1" is supposed
>to signify.
>
The document in question talkes about an approach - using terms such as
"you can", "you may", "the preferred approach", etc. The document in
question is introducing Avalon by example and takes the reader through
the rationale and justification for the existance of ECM. My -1 is a
vocal objection to the assertion that the principals and best practices
sited in that particular document constitute binding defintions.
>The fact that it isn't properly represented in the javadocs
>documentation doesn't negate the fact that historically the team came
>to that conclusion. It does not negate the fact that it was the
>tradition imposed by Federico, who convinced both Peter and I (no small
>feat I might add) that it was the best way.
>
Sorry - I disagree. The javadoc is part of what we have voted on. We
put in place ServiceManager as the replacement of ComponentManager and
we voted on that - we voted on the implementation sources and the
javadoc. Those sources were for all intensive purposes totally
equivalent to ComponentManager - and neither describe any such
historical conclusion. Lets get real - when we produce framework
content the javadoc is part of the defintion.
>
>With this restriction, I looked at ways of programatically enforcing the
>Role to be the interface class, or something more concrete.
>Unfortunately, the interface class won't work because of classloader
>issues (if a class is loaded in separate classloaders, it is considered
>to be a different class). And I have not been able to come up with an
>agreeable object that enforces the role abstraction. The important
>thing is that the Role is tightly coupled to its interface--and as such
>the lookup name should be the Role's interface name.
>
This is only true in the ExcaliburComponentManager scenario.
It is not true of the general case. The general case is much simpler -
a component request a service from its manager by using the role
argument. It is a implementation issue as to how a CM/SM is populated
in order to satisfy the component requests. The moment you are
introducing any semantics into the role value - you imply a contract
between the container the the component. If you were to take that
component as stick it into Phoenix and Merlin it would be supplied with
a DefaultComponentManager or DefaultServiceManger implementation and as
you know, both implmementations are strictly consistent with the
resopective interface definitions - i.e. the role is a string that is
used by the component to reference a dependent service/component.
Neither DCM or DSM do anything related to classloading - they are
supplied with prepared services/components.
>
>The decision stems from the best way to have a unique name for a role,
>without being subject to naming clashes. It would be really bad and
>incorrect if I received a component implementing
>"com.infoplanning.Store" when I really wanted something implementing
>"org.apache.excalibur.Store".
>If the role name in the CM was simply "Store", which one should the
>container return? Under which circumstances should it return the
>"com.infoplanning" version and which circumstances should it return the
>"org.apache.excalibur" version? The reality is that they are separate
>roles.
>
Hang on ----- I create a component - it has needs three service, its
refers to those services using roles "fred", "george" and "mary". The
role names are simply the keys used by the component to locate the
services - they are not defintions of what the service is (at least at
the level of the Avalon framework). These keys are also unique within
the scope of the component - a.k.a. it's a component conecern. A
particular container may choose to provide a dynamic CM/SM - one that
recoginises certain semantics with respect to role names that are
supplied to a CS/SM - but that's simply an implementation approach that
is restricted to a family of components that are portable within that
context. What you cannot do is to infer those implemetation semantics
onto framework interfaces. The approach taken to the establishment of a
functional CM/SM is orthogonal to the specific question of key used by
the component to lookup the service.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>>It is a tradition, a recommendation, and a "best practice". It is _not_
>>>a requirment.
>>>
>>>
>>I have to question this "best practice".
>>
>>
>
>it is because your components will be useable in the broadest possible
>scope: ECM, phoenix, SM, merlin, ... very importantly: cocoon.
>
>And it doesn't really "hurt". Or does it? (...)
>
>
That's the key question.
Avalon Framework is the reference point - but the framework does not
define "how" a container should be implemented - which is a good thing.
This independence from container implementation has allowed the
emergence of different implementation approaches - ECM, SM, Phoenix,
Merlin, etc. In each case there is the introduction of additional
information constructs which help to simplify/control/automate the
process of component management (in the broad sense of the word).
However, these additions basically represent families in terms of
component portability. The only way to avoid this is to address
interoperability interfaces - basically isolating and resolving the
differences between approaches and from that, establishing a common
ground. For example, the ongoing metainfo/metadata activity is a result
of identification and isolation of a object model that will enable a
high level of interoperability between Phoenix and Merlin. At this time
both Phoenix and Merlin use the DefaultServiceManger and
DefaiultComponentManager implementations - however, that decision can be
abstracted out by using a provider. The combination of an open model
for the declaration of a component type together with pluggable
providers will lead to complete interoperability across components. But
this requires that we be very strict about separation and isolation of
assumptions and practices that effect the component contract. For
example, the notion of role == interface name + magic keywords makes
sense for a specific class of container. In such a scenario, the
component must be able to declare that it is dependent on type of CM/SM
- and this is meta info (information about the component type). A
kernel can recognize and apply these constraints providing we establish
a common component type model.
Without that in place, the addition of any semantics over and above the
framework notions will "hurt" if and when you switch a component from
one family to another.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> >It is a tradition, a recommendation, and a "best practice". It is _not_
> >a requirment.
>
> I have to question this "best practice".
it is because your components will be useable in the broadest possible
scope: ECM, phoenix, SM, merlin, ... very importantly: cocoon.
And it doesn't really "hurt". Or does it? (...)
> >We could tighten this to the lookup name should start with the results
> >of getClass().toString() called on the role interface, minus the
> >starting "interface ".
>
> This would introduce an artifical and unnecessary limitation?
yes. Notice the "could" instead of "should". Practical usage of avalon
framework wouldn't really be a lot more difficult either way - just some
potential extra typing work.
> >You forget the other alternative allowed (regardless of whether this is
> >by code or contract) is for framework users to be their own authority.
>
> The scalable approach is for the component to manage its own role
> namespace (through a clean seperation of lookup role and the
> computational dependecy).
you put it so much clearer =)
> >- Leo, who always follows "best practice" in his own projects
>
> Steve - who tends question and understand why something is a best
> practice before following.
>
> :-)
we at avalon tend to do that into the extreme...sometimes following the
herd (yes there's a distant pun ;) works just as well...
:D
- Leo, sometimes uses quotes ("") to denotate more than just strings
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>On Wed, 12 Jun 2002 11:50, Stephen McConnell wrote:
>
>> 2. the concern related to ECM
>>
>> ECM uses the role name together with some implementation
>> magic to support resolution of services exposed under the
>> component manager interface. In this context, the association
>> of an interface name as a key value is consistent with the
>> design of ECM.
>>
>
>And phoenix. ie It is less work to comply with this than it is not to comply
>and all of cornerstone and friends comply with it. If you comply then you
>need not define <role> elements and your .xinfo files are cut by a third.
>
No problem with the notion that in the context of no role declaration at
the level of meta information then the role name is asumed to be the
class name of the request services. That's not in conflict. Its a
"convention"that can be applied by a container in the absence of other
information - not a "best practice". The application of the convention
can be a recommendation - but the overriding rule is that a component is
control of its own role naming scope.
>
>I am not saying it should always be enforced but it can be recomended.
>
I agree that this can recommended as a naming convention on that grounds
of things like default values.
>ie I
>have been asked in the past to put in a check. For every role string do
>something like
>
>int index = role.indexOf( '/' );
>if( -1 != index )
>{
> role = role.substring( 0, index );
>}
>
>if( role != interfaceName )
>{
> issueWarning();
>}
>
>I consider it valid best practice in any container. It need not be enforced
>but it is good to do.
>
I really object to the "issue a warning" - simply because this is not
the kernel concern. A component using "Fred", "George" and "Mary" as
role names is valid and consistent. In conclusion - the application of a
the convention of interface names is valid for defaults. Secondly, I
agree with the convention that role names should be assigned under
public static KEY value as means to address key management. I do not
agree that the value returned from KEY should be considered as anything
but opaque as far as a container or kernel is concerned. See prev.
email for snipped rationale.
:-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Wed, 12 Jun 2002 11:50, Stephen McConnell wrote:
> 2. the concern related to ECM
>
> ECM uses the role name together with some implementation
> magic to support resolution of services exposed under the
> component manager interface. In this context, the association
> of an interface name as a key value is consistent with the
> design of ECM.
And phoenix. ie It is less work to comply with this than it is not to comply
and all of cornerstone and friends comply with it. If you comply then you
need not define <role> elements and your .xinfo files are cut by a third.
I am not saying it should always be enforced but it can be recomended. ie I
have been asked in the past to put in a check. For every role string do
something like
int index = role.indexOf( '/' );
if( -1 != index )
{
role = role.substring( 0, index );
}
if( role != interfaceName )
{
issueWarning();
}
I consider it valid best practice in any container. It need not be enforced
but it is good to do. If you remember I asked you why you did not do this
with enterprise stuff because people had emailed me asking why the -apps CVS
did not live up to what we/I recomended ;)
So I think it is good practice that the rolename is serviceClazz.getName(),
optionally with a "selector" on end like "/ssl".
> p.s. sins concerning metainfo back-pointers are forgiven
> - a solution has emerged :-)
aww, sinners get more lasses.
--
Cheers,
Peter Donald
------------------------------------------------------------
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: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 03:20 AM 6/14/2002 +0200, you wrote:
>Peter Donald wrote:
>
>>
>>>Open Questions:
>>>---------------
>>>
>>>And what about Fortress ? Where does Fortress fit within this picture?
>>>What is the potential for Fortress extending a generic abstract assembly
>>>framework. Are the ECM constraints concerning the CM lookup argument
>>>semantics also applicable? Does Fortress bring any new
>>>issues/opportunities to the table?
>>
>>
>>If you and Leo cooperate then from what I understand Fortress is very
>>similar to Merlin except that it does Pooling/Recycling of components on
>>release()
>
>
>Which of out distinguished Leo's are we referring to ?
If I said LS would you hit me with a big stick? ;)
Leo Sutic co-author of Fortress
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>
>> Open Questions:
>> ---------------
>>
>> And what about Fortress ? Where does Fortress fit within this
>> picture? What is the potential for Fortress extending a generic
>> abstract assembly framework. Are the ECM constraints concerning the
>> CM lookup argument semantics also applicable? Does Fortress bring any
>> new issues/opportunities to the table?
>
>
> If you and Leo cooperate then from what I understand Fortress is very
> similar to Merlin except that it does Pooling/Recycling of components
> on release()
Which of out distinguished Leo's are we referring to ?
S
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 01:45 AM 6/14/2002 +0200, you wrote:
>I'm going to try and rephrase this. In the context of ECM (as a component
>factory serving dynamic request - and lacking support for component
>dependency declarations), a single flat key is insufficient to describe
>both an interface name and preferred implementation.
True but the role string is not meant to declare the constraints it is
meant to name a set of constraints. The primary constraint being the type
of the component.
so lets say that Consumer Component A has a dependency P on a component
that satisfies the constraints x, y and z.
Component: A
Dependency: P
Constraints of P: x, y ,z
Usually there is only one constraint (lets say x) and that is that the
component that provides dependency P is of a certain type. By convention P
is the name of type.
>Open Questions:
>---------------
>
>And what about Fortress ? Where does Fortress fit within this picture?
>What is the potential for Fortress extending a generic abstract assembly
>framework. Are the ECM constraints concerning the CM lookup argument
>semantics also applicable? Does Fortress bring any new
>issues/opportunities to the table?
If you and Leo cooperate then from what I understand Fortress is very
similar to Merlin except that it does Pooling/Recycling of components on
release()
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I'll keep only the most relevant parts.
I think you got the idea :-)
Stephen McConnell wrote:
>
> Nicola Ken Barozzi wrote:
>
> Nicola:
>
>> Stephen McConnell wrote:
>> >
>> >
> components under the Phoenix/Merlin model are constrained in that they
> cannot acquire a service type that is not known at build time,
> furthermore, the scope of the role is constrained to a handful of services.
Correct.
>> -oOo-
>>
>> Basically, it seemed natural to me and to others to specify the
>> component as a role+behaviour.
>>
>> role=java interface
>> behaviour="way" of working
>
>
>
> Which makes sense in the ECM context. Within ECM, the component has the
> overhead of having to be concerned about getting the right component
> implementation. The <ecm-role> includes a <service-interface-class-name>
> which means you will get the right type, but the <hint> becomes a
> sensitive subject because this is the mechanism for ensuring you get the
> right service implementation class.
Usually true ATM, but not necessarily.
A hint is now mapped to an implementation, but it also could be mapped
to a class of implementations that can be seen for the user as the same
implementation.
> In Phoenix/Merlin this issue simply
> does not exist because the set of services in the component manager are
> restricted to only those declared by the component and tagged using a
> string to represent the usage (which also happens to be called the
> "role).
Correct.
ECM in cocoon is used as a base for a second container, which is the
sitemap.
In essence we have two containers, one serving the other.
> 1. Cocoon starts.
> 2. Cocoon reads a configuration containing component class names and
> the associated <ecm-role> declarations and registers these with a
> root ECM instance.
> 3. Cocoon reads a sitemap during which it creates an ECM instance for
> the sitemap processing and during evaluation of the map, it locates
> processing instruction which can be de-referenced to <ecm-role> values.
> 4. Cocoon causes these instructions to be materialized by instantiating
> and pipelining a component to the job.
+1
> I'm going to try and rephrase this. In the context of ECM (as a
> component factory serving dynamic request - and lacking support for
> component dependency declarations), a single flat key is insufficient to
> describe both an interface name and preferred implementation.
Preferred behaviour.
If I request a Transformer (role), and specify Jaxp (hint), I could get
any comapatible one.
> Open Questions:
> ---------------
>
> And what about Fortress ? Where does Fortress fit within this picture?
> What is the potential for Fortress extending a generic abstract assembly
> framework. Are the ECM constraints concerning the CM lookup argument
> semantics also applicable? Does Fortress bring any new
> issues/opportunities to the table?
>
> And what about Phoenix? What are the specific assumptions that Phoenix
> makes with respect to a <ecm-role> lookup arguments in the context of
> it's strict declaration of implementation to service usage mappings?
Any reply takers? ;-)
> Interim Conclusions:
> --------------------
>
> 1. ECM places a specific implementation constraint on a component
> resulting from
> lookup argument value semantics.
> 2. A component implementation that accesses these lookup semantics
> should, as a
> minimum, declare this assumption in the meta-info for the type.
> 3. A generic container should be able to access via a simple API, such a
> policy
> and provide for rapid failure if it is unable to provide support for the
> declared policy.
> 4. The impact of point (3) is that pre-runtime-validation can occur
> through tools
> and this can include ECM dependent components (keeping in mind that an ECM
> component may also have a policy of not declaring dependencies - i.e.
> negating
> the potential validation against the benefit of dynamic lookup).
> 5. Enabling the runtime selection of an appropriate component manager
> capable of
> handling the policy implied by the client requires a more formal
> definition of
> a CM provider (i.e. we are not talking about a container here). Merlin II
> would need to be able to instantiate an ECM (as ComponentManager /
> Component
> Implementation Repository / Service Registry) to service a component
> exposing an CUSTOM_CM_TYPE policy (and I haven't really thought through the
> implications of this just yet).
> 6. Looking at this from the opposite direction, ECM (as ComponentManager /
> Component Implementation Repository / Service Registry ) should be able to
> handle recognition of non-ECM components. Actually, the totally elegant
> solution would be for ECM to be re-cut as an extension of a generic
> service such that the only time it actually got involved in the process
> would be in relation to ECM specific components (a.k.a. dynamic lookup
> component).
Seems correct.
The question now: how do we handle-specify the key of the locator?
> (who is now much more confident that "role" == "different things for
> different people")
;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
Nicola:
First of all - thanks for the reply - I really appreciate the time and
effort.
Not everything is clear just yet but the reasons for the
problem/issues/differences and rationale behind the ECM implementation
approach are starting to come into focus. I'll try to summarize my
interpretation of these points as I go though your email. If I'm
asserting something that is incorrect - please jump up and down - some
of my notes are making quantum leaps based on principals which may not
be supported by facts.
> Stephen McConnell wrote:
> >
> >
> > Peter Donald wrote:
> >
> >>> Attempt at enforcing the "principal" that a key corresponds to an
> >>> interface effectively negates the potential for multiple service
> >>> provision where a interface is shared by more than one provided
> service
> >>
> >>
> >> No it does not. Decorate it at end with a "/key" and voila multiple
> >> service provision of service with same interface.
> >
>
> Ok, I'll try to give my opinion on this.
>
> <note>
> BTW, it seems I'm not the only one that gets frustrated ;-) on these
> discussions that are full of meaning and where it's humanly hard to
> understand what the others think. It's because we *really* want to
> understand and get the best, and this is good :-)
> </note>
>
>
> > LET ME MAKE THIS REAL CLEAR,
> > I WANT TO KNOW WHY "org.apache.Thing/key" is any different to
> > "something" in the context of a component lookup key value.
>
> Not different.
> Your phrase is correct.
>
> The point is: what do you want to lookup?
>
> a) a component in a named list of components
> b) a component in a *hierarchy* of components
>
> > IF THE ANSWER IS THAT IT MUST BE DONE THAT WAY TO BE COMPATABLE WITH A
> > PARTICULAR CONTAINER THEN THIS IS PLAIN BAD, BAD, BAD - AND SHOULD BE
> > DRAGGED IN THE OPEN - REVIWED, AND DISCUSSED OPENLY. If it is not the
> > case - then *please* explain *what* my stubborn, irrational and
> > ill-informed actions are breaking.
>
> We could break the *hierarchy* use of the lookup.
>
> What do I mean by hierarchical?
> Basically the same thing as in OOP classes.
>
> An example that I like is the (made up) Connection role.
>
> CASE 1
> --------
> Let's say that we have a Connection role that is mapped (in some way,
> let's not get into classname-versus-id thing) to the
> org.apache.ciao.Connection.
>
> Then we have three implementations:
> org.apache.ciao.TcpConnection
> org.apache.ciao.UdpConnection
> org.apache.ciao.TcpSSLConnection
> org.apache.ciao.UdpSSLConnection
>
> If a component wants a Connection Component, the container can give
> any and the user is ok with it.
>
> CASE 2
> --------
> Now, let's say that the Component wants to have a Connection Component
> that is secure, such as org.apache.ciao.TcpSSLConnection.
>
> I could create the role SecureConnection, and map it to
> org.apache.ciao.SecureConnection that /extends/ Connection.
> I have
> org.apache.ciao.TcpSSLConnection
> org.apache.ciao.UdpSSLConnection
> that the container can give.
>
> Or I could create the "subrole" Secure, and ask for a
> "Connection/Secure" Object.
To summarize - ECM is maintaining a hierarchy that follows the pattern
of a structured definition of what a role string is, where:
<ecm-role> == <service-interface-class-name> [ <hint> ]
<hint> == <path> [ <reserved-element> ]
<path> == <delimiter> <key> [ <path> ]
<key> == string representing a node in the hierarchy
<reserved-element> == <delimiter> "Selector" | ???
<delimiter> == "/"
A second import difference that should be recognized is that ECM does
not appear to recognize a dependency. When a client requests a new
component by invoking lookup, ECM attempts to resolve that request by
interpreting the <ecm-path> resulting in the return of an existing
component instance, or, the instantiation of a new Component and the
processing of the component's lifecycle and providing itself as the
ComponentManager and source for active component resolution of
dependencies (i.e. the component being composed can ask for a subsidiary
dependency <ecm-role> which implies that a single ECM instance in some
form or another represents a security scope). On the rash assumption
that I have got this correct, I would like to emphasize that this is
very different to Phoenix/Merlin approaches in which the CM supplied
instance only contains the services that are explicitly declared under
<dependency/> declarations. This difference is significant in that
components under the Phoenix/Merlin model are constrained in that they
cannot acquire a service type that is not known at build time,
furthermore, the scope of the role is constrained to a handful of services.
>
>
> -oOo-
>
> Basically, it seemed natural to me and to others to specify the
> component as a role+behaviour.
>
> role=java interface
> behaviour="way" of working
Which makes sense in the ECM context. Within ECM, the component has the
overhead of having to be concerned about getting the right component
implementation. The <ecm-role> includes a <service-interface-class-name>
which means you will get the right type, but the <hint> becomes a
sensitive subject because this is the mechanism for ensuring you get the
right service implementation class. In Phoenix/Merlin this issue simply
does not exist because the set of services in the component manager are
restricted to only those declared by the component and tagged using a
string to represent the usage (which also happens to be called the
"role). Phoenix goes further than Merlin in that Phoenix provides
support for the explicit association of a service reference to the
implementation class. In Merlin the equivalent is on the drawing board -
it basically follows the same pattern as the rest of Merlin - if there
is an unambiguous default solution then use it.
>
>
> Now, as you are not using interfaces as markers, I understand that you
> have a defined list of roles with the components to give to your app...
>
> Which you cannot do in all cases.
>
> Take Cocoon for example.
> The sitemap uses and assembles Components based on their role, but
> requests them based on the behaviour (hint).
Let me summarize that using different words:
1. Cocoon starts.
2. Cocoon reads a configuration containing component class names and
the associated <ecm-role> declarations and registers these with a
root ECM instance.
3. Cocoon reads a sitemap during which it creates an ECM instance for
the sitemap processing and during evaluation of the map, it locates
processing instruction which can be de-referenced to <ecm-role> values.
4. Cocoon causes these instructions to be materialized by instantiating
and pipelining a component to the job.
>
> In essence, it uses Roles as generic interfaces to the Role+hint key.
>
> ***************
> What single flat keys lack is the possibility of requesting different
> components that have different behaviours in different moments, while
> keeping the same role.
> ***************
I'm going to try and rephrase this. In the context of ECM (as a
component factory serving dynamic request - and lacking support for
component dependency declarations), a single flat key is insufficient to
describe both an interface name and preferred implementation.
Open Questions:
---------------
And what about Fortress ? Where does Fortress fit within this picture?
What is the potential for Fortress extending a generic abstract assembly
framework. Are the ECM constraints concerning the CM lookup argument
semantics also applicable? Does Fortress bring any new
issues/opportunities to the table?
And what about Phoenix? What are the specific assumptions that Phoenix
makes with respect to a <ecm-role> lookup arguments in the context of
it's strict declaration of implementation to service usage mappings?
Interim Conclusions:
--------------------
1. ECM places a specific implementation constraint on a component
resulting from
lookup argument value semantics.
2. A component implementation that accesses these lookup semantics
should, as a
minimum, declare this assumption in the meta-info for the type.
3. A generic container should be able to access via a simple API, such a
policy
and provide for rapid failure if it is unable to provide support for the
declared policy.
4. The impact of point (3) is that pre-runtime-validation can occur
through tools
and this can include ECM dependent components (keeping in mind that an ECM
component may also have a policy of not declaring dependencies - i.e.
negating
the potential validation against the benefit of dynamic lookup).
5. Enabling the runtime selection of an appropriate component manager
capable of
handling the policy implied by the client requires a more formal
definition of
a CM provider (i.e. we are not talking about a container here). Merlin II
would need to be able to instantiate an ECM (as ComponentManager / Component
Implementation Repository / Service Registry) to service a component
exposing an CUSTOM_CM_TYPE policy (and I haven't really thought through the
implications of this just yet).
6. Looking at this from the opposite direction, ECM (as ComponentManager /
Component Implementation Repository / Service Registry ) should be able to
handle recognition of non-ECM components. Actually, the totally elegant
solution would be for ECM to be re-cut as an extension of a generic
service such that the only time it actually got involved in the process
would be in relation to ECM specific components (a.k.a. dynamic lookup
component).
Cheers, Steve.
(who is now much more confident that "role" == "different things for
different people")
SJM
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>>> Attempt at enforcing the "principal" that a key corresponds to an
>>> interface effectively negates the potential for multiple service
>>> provision where a interface is shared by more than one provided service
>>
>>
>> No it does not. Decorate it at end with a "/key" and voila multiple
>> service provision of service with same interface.
>
Ok, I'll try to give my opinion on this.
<note>
BTW, it seems I'm not the only one that gets frustrated ;-) on these
discussions that are full of meaning and where it's humanly hard to
understand what the others think. It's because we *really* want to
understand and get the best, and this is good :-)
</note>
> LET ME MAKE THIS REAL CLEAR,
> I WANT TO KNOW WHY "org.apache.Thing/key" is any different to
> "something" in the context of a component lookup key value.
Not different.
Your phrase is correct.
The point is: what do you want to lookup?
a) a component in a named list of components
b) a component in a *hierarchy* of components
> IF THE ANSWER IS THAT IT MUST BE DONE THAT WAY TO BE COMPATABLE WITH A
> PARTICULAR CONTAINER THEN THIS IS PLAIN BAD, BAD, BAD - AND SHOULD BE
> DRAGGED IN THE OPEN - REVIWED, AND DISCUSSED OPENLY. If it is not the
> case - then *please* explain *what* my stubborn, irrational and
> ill-informed actions are breaking.
We could break the *hierarchy* use of the lookup.
What do I mean by hierarchical?
Basically the same thing as in OOP classes.
An example that I like is the (made up) Connection role.
CASE 1
--------
Let's say that we have a Connection role that is mapped (in some way,
let's not get into classname-versus-id thing) to the
org.apache.ciao.Connection.
Then we have three implementations:
org.apache.ciao.TcpConnection
org.apache.ciao.UdpConnection
org.apache.ciao.TcpSSLConnection
org.apache.ciao.UdpSSLConnection
If a component wants a Connection Component, the container can give any
and the user is ok with it.
CASE 2
--------
Now, let's say that the Component wants to have a Connection Component
that is secure, such as org.apache.ciao.TcpSSLConnection.
I could create the role SecureConnection, and map it to
org.apache.ciao.SecureConnection that /extends/ Connection.
I have
org.apache.ciao.TcpSSLConnection
org.apache.ciao.UdpSSLConnection
that the container can give.
Or I could create the "subrole" Secure, and ask for a
"Connection/Secure" Object.
-oOo-
Basically, it seemed natural to me and to others to specify the
component as a role+behaviour.
role=java interface
behaviour="way" of working
Now, as you are not using interfaces as markers, I understand that you
have a defined list of roles with the components to give to your app...
Which you cannot do in all cases.
Take Cocoon for example.
The sitemap uses and assembles Components based on their role, but
requests them based on the behaviour (hint).
In essence, it uses Roles as generic interfaces to the Role+hint key.
***************
What single flat keys lack is the possibility of requesting different
components that have different behaviours in different moments, while
keeping the same role.
***************
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 03:07 AM 6/14/2002 +0200, you wrote:
>array of services, dependencies, local versus remote, etc.). But Phoenix
>is too hard for the sort of customer who want's what I have. I would end
>up doing site visits to fix their systems with minor errors in
>assembly.xml or config.xml. That means time and effort from both me, my
>team, and my customer. My preoccupation is that a large degree of this is
>redundant - the errors are actually introduced by the user because the
>platform is forcing the user to declare too much. The anti-
Oh - now I get what you mean. You don't like having to use classname in
assembly.xml !
With that I actually agree. If you look at ECM, Fortress, Myrmidon they
also agree - it is only phoenix that forces you to use the long name ;)
In ECM and friends we have the notion of a RoleManager (and also a
TypeManager in myrmidon). Basically this maps the classname to a shortname.
Then assemblers then use the shortname rather than long-name.
In myrmidon we have just decided to automagically manage shortnames aswell
via overidable auotmapping system. ie org.apache.antlibs.core.IfTask maps
to "if" in "task" type. org.apache.antlibs.core.StringToFileConverter maps
to "string-to-file" in "converter" type etc.
Similar things happen in cocoon land.
We could even attempt to do this in Phoenix. ie suck the
shortname->classname mappings from block jars prior to processing
assembly.xml. If version="1.1" on assembly.xml then we use shortnames else
we use the system we have now.
>Which falls back to the interface != service scenario.
>The role name that Merlin deals with (and Phonix) is linked to a service
>which is interface and version. If the recommendation was clear and
>precision about the defintion of a service interface (via a static
>declaration) then I'm starting to move to your position.
Not sure what I have to do to convince you? Isn't that we already do?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 12:07 PM 6/13/2002 +0200, you wrote:
> LET ME MAKE THIS REAL CLEAR,
>
>> I WANT TO KNOW WHY "org.apache.Thing/key" is any different to
>> "something" in the context of a component lookup key value.
>
>
> Because everyone but you follow the first convention.
I know, but it's tough when your leading a Renaissance
... truth, discovery, understanding, reality, delivery, progress -
someone has to take the lead.
:-)
> Thats the main reason.
I can live that because the convention is completely unqualified.
There convention delivers an apparent fix - but in reality, the
convention only solves 80% of the question and remaining 20%^ is throw
into a basket called learning cure. I may be the only one here concerned
with the scaling down of the leaning curve - but that's something I'm
happy living with - in my old age I'll look back and smile.
> You can choose to follow our conventions or not - depends on how
> widely used you want your components to be ;)
Its more that that.
Today, my number 1 priority is to deliver maintainable and manageable
solutions for global service management. What this entails is the
delivery of a platform that is easy to maintain. Phoenix stacks up as a
very good computational solution for the problems I'm dealing with (a
really complex array of services, dependencies, local versus remote,
etc.). But Phoenix is too hard for the sort of customer who want's what
I have. I would end up doing site visits to fix their systems with minor
errors in assembly.xml or config.xml. That means time and effort from
both me, my team, and my customer. My preoccupation is that a large
degree of this is redundant - the errors are actually introduced by the
user because the platform is forcing the user to declare too much. The
anti-Christ in this situation is a platform that only raised an issue if
there is an issue to raise. The smaller the user intervention, the
smaller the cost of user support, and a commensurate increase in the
bottom line. If your personally covering a bottom line you will
understand what I'm talking about. Why am I mentioning Phoenix here -
because Phoenix is backed by a great implementation and a lot of
documentation. And yet there are issue with usability. That's not a
complaint - its an observant focussed on my needs as a user of Avalon
-more is need, more flexibility, more integrity.
>
> In 99% of cases you don't need they "/key" postfix. And thus reasons
> being;
The Avalon component model gives me integrity withikn a qualified scope
- we are only just starting to explore the ECM question. In this process
comes practices that are banded about as recommendations that in all
honesty should be classified as workarounds for interoperabilty issues
that will probably sole 99% of the cases. In the 1% that occur, and my
team have to try to track down the issue and days later they confirmed
to me that's its an undocumented 1% situation which should never happen.
So the team have the responsibity of fixing this. The budget they are
working on is the margin from the over 99 customers that by chance have
not encountered this problem to-date. Every day that they spend on the
problem costs me the margin I gain from 4.3 customers. If you want to
get to the issue - its two things - firstly, ECM has an computational
contract with its components that is at best badly documented and even
worse, the second issue - hidding behind phrase of "beastpractive" and
"recommendation".
>
> * automagically maintained. ie if you change the package of service
> interface you don't have to worry that you forgot to update the ROLE
> string.
seperate concern - nothing to do with the lookup operation semantics.
>
> * You can reuse the ROLE string in interface across multiple consumers
> without worrying about name clashes.
Fudge.
The role string is semantically significant when passed to ECM. Yes, if
you declared public static final String ECM_ROLE I would agree. If a
convention were introduced from the declaration of a public static final
Version VERSION in an interface I would +1 it immeiately and push for
its escalation to the level of a real "best-practive". If I want the the
class name of an iterface I can use <classname>.class and I know a
compiler error will tell me if something is wrong.
>
> * don't need to worry about maintaining <role> in dependency for
> component as it is auto maintained for you
> etc.
Which falls back to the interface != service scenario.
The role name that Merlin deals with (and Phonix) is linked to a service
which is interface and version. If the recommendation was clear and
precision about the defintion of a service interface (via a static
declaration) then I'm starting to move to your position.
> Anyways most containers require or at least show a preference for the
> pattern and it has been a fairly established pattern.
Established, but unqualifed and incomplete.
Its correctable, but its also BAD, just plain but bad bad.
> Why not save yourself the extra work and follow suite? Maintaining
> role strings in 4 difference places and remembering to change them
> when you move the interface is something you can do if you want. Don't
> expect anyone else to feel sympathy for you though ;)
Trust me - I'm saving myself extra work by ensuring that my sytems work
in 100% of post validation cases. 99% is just not good enough.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 12:07 PM 6/13/2002 +0200, you wrote:
LET ME MAKE THIS REAL CLEAR,
>I WANT TO KNOW WHY "org.apache.Thing/key" is any different to "something"
>in the context of a component lookup key value.
Because everyone but you follow the first convention. Thats the main
reason. You can choose to follow our conventions or not - depends on how
widely used you want your components to be ;)
In 99% of cases you don't need they "/key" postfix. And thus reasons being;
* automagically maintained. ie if you change the package of service
interface you don't have to worry that you forgot to update the ROLE string.
* You can reuse the ROLE string in interface across multiple consumers
without worrying about name clashes.
* don't need to worry about maintaining <role> in dependency for component
as it is auto maintained for you
etc.
Anyways most containers require or at least show a preference for the
pattern and it has been a fairly established pattern. Why not save yourself
the extra work and follow suite? Maintaining role strings in 4 difference
places and remembering to change them when you move the interface is
something you can do if you want. Don't expect anyone else to feel sympathy
for you though ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>> Attempt at enforcing the "principal" that a key corresponds to an
>> interface effectively negates the potential for multiple service
>> provision where a interface is shared by more than one provided service
>
>
>
> No it does not. Decorate it at end with a "/key" and voila multiple
> service provision of service with same interface.
LET ME MAKE THIS REAL CLEAR,
I WANT TO KNOW WHY "org.apache.Thing/key" is any different to
"something" in the context of a component lookup key value.
IF THE ANSWER IS THAT IT MUST BE DONE THAT WAY TO BE COMPATABLE WITH A
PARTICULAR CONTAINER THEN THIS IS PLAIN BAD, BAD, BAD - AND SHOULD BE
DRAGGED IN THE OPEN - REVIWED, AND DISCUSSED OPENLY. If it is not the
case - then *please* explain *what* my stubborn, irrational and
ill-informed actions are breaking.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
<mycomponent logger="mycomponent">
</mycomponent>
We can name our logger categories anything we want--and Fortress/ECM
(/Myrmidon?) will give it to you the way you want it.
Not that hard...
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Wednesday, June 12, 2002 8:35 PM
> To: Avalon Developers List
> Subject: Re: [proposal] avalon 5 ComponentManager interface
>
>
> At 03:50 AM 6/12/2002 +0200, you wrote:
> > 2. the concern related to ECM
> >
> > ECM uses the role name together with some implementation
> > magic to support resolution of services exposed under the
> > component manager interface. In this context, the association
> > of an interface name as a key value is consistent with the
> > design of ECM.
>
>
> And myrmidon and fortress and Phoenix/Merlin also encourage it by not
> requiring bulkage in config files if not the case.
>
> > This may be a valid best practice within the scope of ECM
> > but it is inconsistent with the specifications at the
> framework
> > level.
> >
> >Attempt at enforcing the "principal" that a key corresponds to an
> >interface effectively negates the potential for multiple
> service provision
> >where a interface is shared by more than one provided service
>
>
> No it does not. Decorate it at end with a "/key" and voila
> multiple service
> provision of service with same interface.
>
>
> >(without resorting to implementation workarounds such as a component
> >selector). This is simply because keys are dealing with
> "instances" of
> >services that a component implementation requires.
> Interface names are
> >"type" level. While interface names may be convenient in the
> majority of
> >cases - it is not definitive and any attempt to enforce the
> rule will not
> >only introduce unnecessarily constraints on a developer -
> but will also
> >break existing components with more subtile role/service
> relationship.
>
> Im not sure exactly what the problem is. It is enforced in several
> containers, is implemented in all the avalon hosted
> components (except
> yours) and by following pattern you can reuse component
> between multiple
> containers.
>
> When I asked you why you not follow pattern you told me it was for
> pragmatic reasons - ie role name == name of logger used for
> dependency.
> However this could easily be stored as an attribute of
> dependency so I am
> not sure that still holds?
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@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: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 03:50 AM 6/12/2002 +0200, you wrote:
> 2. the concern related to ECM
>
> ECM uses the role name together with some implementation
> magic to support resolution of services exposed under the
> component manager interface. In this context, the association
> of an interface name as a key value is consistent with the
> design of ECM.
And myrmidon and fortress and Phoenix/Merlin also encourage it by not
requiring bulkage in config files if not the case.
> This may be a valid best practice within the scope of ECM
> but it is inconsistent with the specifications at the framework
> level.
>
>Attempt at enforcing the "principal" that a key corresponds to an
>interface effectively negates the potential for multiple service provision
>where a interface is shared by more than one provided service
No it does not. Decorate it at end with a "/key" and voila multiple service
provision of service with same interface.
>(without resorting to implementation workarounds such as a component
>selector). This is simply because keys are dealing with "instances" of
>services that a component implementation requires. Interface names are
>"type" level. While interface names may be convenient in the majority of
>cases - it is not definitive and any attempt to enforce the rule will not
>only introduce unnecessarily constraints on a developer - but will also
>break existing components with more subtile role/service relationship.
Im not sure exactly what the problem is. It is enforced in several
containers, is implemented in all the avalon hosted components (except
yours) and by following pattern you can reuse component between multiple
containers.
When I asked you why you not follow pattern you told me it was for
pragmatic reasons - ie role name == name of logger used for dependency.
However this could easily be stored as an attribute of dependency so I am
not sure that still holds?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> 2. the concern related to ECM
Steve, the interface class name matching the interface predates
the ECM. Please don't confuse it as such. The ECM is not what
you are debating, so don't mix that concern in there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <ma...@leosimons.com>.
> Any reasonable container needs to be able to establish the following
> information:
>
> 1. the class of the component
> 2. the service interface class names and lookup keys
> 3. a configuration / parameter description
> 4. a context declaration
>
> From here is just plan lifecycle management. So lets try to pull
> together a summary of how each container handles resolution of the above
> information.
>
> These are the two containers I know "intimately".
that's a me-too there.
> Could we get a similar summary for the other two containers?
and here I can't really help :/
> >nope. As container behaviour is undefined in the framework, you cannot
> >be sure whether it does any interpretation.
> >
>
> On this I agree.
>
> >You'd have to check with the container.
> >
>
> Which is where we are getting into trouble. Nothing at the level of the
> component runtime should need to be aware of a container approach. In
> principal, one component implementation should be able to be deployed
> with multiple meta-data sets. And in principal, if the component
> respects the Avalon interfaces and lifecycle semantics it should operate
> successfully.
uhm, you'd have to check with the container at deployment time, in the
sense that if the container enforces constraints over and above avalon
framework (which isn't necessarily bad), you need to figure out whether
your component works within those constraints.
I didn't mean "you have to check in some programmatic manner".
> >there is no "should", except it is a convention already in place (like
> >our coding conventions, or the javabeans naming scheme), and it is a
> >convention that allows some clever stuff to happen inside ECM and
> >phoenix when a correct meta information definition is missing.
> >
>
> So we are talking about semantics implied by ECM over and above the
> framework.
not only ECM. Also a lot documentation, which has done so for a long
time. And allmost all current components in avalon CVS.
> From your comment I'm assuming that ECM is using a service class name
> as a lookup key. Given that ECM is hadling the instantiation of my
> component, would it not possible for ECM to check for role-to-service
> mappings during the composition cycle? Or am I getting this all wrong?
I wouldn't know; never wrote a line of code for ECM (I think). Berin
implied a link though.
> Here is the URL for the javadoc of what is currently in place on the
> association graph component.
> http://home.osm.net/assembly/index.html
keep it up...
> >>A third concern is
> >>more of fear that "we" simply slide from "recommending" an approach of
> >>"applying restrictions" - which is already been suggested.
> >
> >we already apply restrictions in practice. The only container with a
> >formal release, known to be in broad use (anyone knows how many results
> >google gives for "cocoon hosting"?) is ECM, which applies these
> >restrictions.
>
> I understand that Fortress shares several characteristics with ECM. Do
> the restrictions we are talking about apply equally to Fortress and ECM
> or is this an ECM specific issue? I would be really interested in
> hearing from anyone involved deeply in Fortress about this.
"me too" again =)
> Yes - because the meta-model I'm working with has an explicit attribute
> detailing the role name and I very much want to apply that model to more
> that just the deployment of a component by a container. That attribute
> should not be polluted due to the requirements of one container type.
> The important point is that we don't hide from this under a
> "recommendation" but instead - deal with issue - figure out and
> understand what is possible now and in the future.
agreed. We could now more formally define the role than we have done,
then deprecate that when we figure out how to do backwards
compatibility. Something like that.
> >it *is* a slippery slope, but we're already on it and climbing back to
> >higher ground will mean we'll have to sever the chain binding us to some
> >of our friends, meaning that they will tumble down the hill.
> >
>
> I'm not convinced of that at this time. I would really like to hear
> from ECM and Fortress people about options. If I understand correctly,
> Leo/2 thinks the dependency/role question can be handled within Fortress
> - if that correct, this is at least lets us address ECM and consider the
> possibility of enhancing ECM to provide something equivalent without
> breaking anything that exists. This would be better for Avalon, and
> better for the Cocoon community too.
yes. I'd like to see that =)
I personally don't care that much -- I have no problem using the
"recommendations" -- as long as we're in agreement and get it all
working.
Since phoenix does (I think) some handy stuff with the role mapping (if
there is none, use the interface name), I'd say that should be possible.
> >In how many of the existing containers do you want your components to
> >work?
> >
>
> Today - 2.
> Merlin and Phonix.
for me: Phoenix and ECM. One for standalone, one for servlet-embedded.
> >How many of the existing components written for those containers
> >that make the same slippery assumption as those containers do you want
> >to work in future containers?
>
> All of them (but I'm limiting by immediate scope to components that are
> agnostic). But seriously - yes there are issues - and those issue need
> to be treated as such, not pushed under the carpet with sweeping
> "best-practice" statements. The issues are totally reasonable - the
> whole notion of container interoperability is a new thing and we should
> confront it honestly.
well put. I think everyone now at least understands that there really is
an issue.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>There is also a part of me that just
>>believes that this is a bad thing - maybe even a subtle evil - and yes,
>>maybe I need a new brain because I haven't been able to come up with the
>>clear definition of the issues. But I'll try again. First of all, lets
>>scope this subject. When I'm talking about a role name I'm explicitly
>>referring to the <role></role> meta element in a dependency descriptor
>>as defined within the Merlin/Phoenix meta-model. This also means that by
>>default the component will not work outside of that context.
>>
>>A dependency declaration:
>>
>><dependency>
>><role>brain</role>
>><service name="org.apache.health.neural.CerebralMass" version="5.0.1"/>
>></dependency>
>>
>>The above dependency is declared within the scope of the component
>>implementation. It is a name chosen by the component implementor to
>>refer to the "service" declaration. First point of concern - a service
>>declaration != interface class name.
>>
>>
>
>no, but some current containers assume tight coupling, as do some
>components.
>
Lets tease this out a little.
Any reasonable container needs to be able to establish the following
information:
1. the class of the component
2. the service interface class names and lookup keys
3. a configuration / parameter description
4. a context declaration
From here is just plan lifecycle management. So lets try to pull
together a summary of how each container handles resolution of the above
information.
Phoenix
1. block declaration in the assembly.xml file
2. dependecy declaration in a <classname>.xinfo file
3. via a configuration file keyed to assembly.xml block name declarations
4. no support
Merlin
1. supplied by a client as the target parameter
2. dependecy declaration in a <classname>.xinfo file
3. via a supplied profile and default configuration
4. via a supplied profile and default context description
These are the two containers I know "intimately".
Could we get a similar summary for the other two containers?
>
>
>>But lets move on. If I put myself
>>in the position of a component - I know I'm going to
>>managed/composed/assembled by a container that understands my dependency
>>declaration, and I know that the information I have provided is
>>sufficient for the container to know what name I will use to lookup the
>>service that I need. I also know contractually that the container is not
>>interpreting or applying any semantic magic relative to the name I
>>supply. I know this because this is the way the framework works and my
>>component is based on the framework contracts and documented semantics.
>>
>>
>
>nope. As container behaviour is undefined in the framework, you cannot
>be sure whether it does any interpretation.
>
On this I agree.
>You'd have to check with the container.
>
Which is where we are getting into trouble. Nothing at the level of the
component runtime should need to be aware of a container approach. In
principal, one component implementation should be able to be deployed
with multiple meta-data sets. And in principal, if the component
respects the Avalon interfaces and lifecycle semantics it should operate
successfully.
>>My second point of concern is that I still have not received a concrete
>>definition of why a role name "should" be linked to the interface class
>>name.
>>
>>
>
>there is no "should", except it is a convention already in place (like
>our coding conventions, or the javabeans naming scheme), and it is a
>convention that allows some clever stuff to happen inside ECM and
>phoenix when a correct meta information definition is missing.
>
So we are talking about semantics implied by ECM over and above the
framework. As I expressed to Pete in that earlier email - this is bad if
your trying to build component that are container agnostic - its fine if
you are coding against ECM. Can we please go into more detail on this.
From your comment I'm assuming that ECM is using a service class name
as a lookup key. Given that ECM is hadling the instantiation of my
component, would it not possible for ECM to check for role-to-service
mappings during the composition cycle? Or am I getting this all wrong?
>>Even if I were to apply this recommendation, my components would
>>still be restricted to the Merlin/Phoenix meta-land.
>>
>>
>
>but that we will fix, right?
>
Yep given that:
1. there is a meta-model at the framework level
2. that the model enables extension (i.e. creation of a derived meta-model)
3. and at least one default implementation
There is already excalibur.containerkit and I have already validated
most of this. Above this I have already put in place a solution for the
automatic creation of a potential association graph. I.e. the solution
does not make any decisions about anything - for example, the graph will
show multiple candidate providers for a particular service if these are
known. It's the steps from here which are container specific - e.g.
resolution of the right service provider in Phoenix is declared in the
assembly.xml file. Resolution of the right service provider in Merlin
is inferred. Resolution in ECM is via a ComponentSelector.
Here is the URL for the javadoc of what is currently in place on the
association graph component.
http://home.osm.net/assembly/index.html
>>A third concern is
>>more of fear that "we" simply slide from "recommending" an approach of
>>"applying restrictions" - which is already been suggested.
>>
>>
>
>we already apply restrictions in practice. The only container with a
>formal release, known to be in broad use (anyone knows how many results
>google gives for "cocoon hosting"?) is ECM, which applies these
>restrictions.
>
>
I understand that Fortress shares several characteristics with ECM. Do
the restrictions we are talking about apply equally to Fortress and ECM
or is this an ECM specific issue? I would be really interested in
hearing from anyone involved deeply in Fortress about this.
>>I fundamentally believe that these sort of actions will make the Avalon
>>learning curve one notch higher that it already is.
>>
>>
>
>yup.
>
>
>
>>A forth concern is
>>directly related to the clarity of component documentation. Unlike
>>objects, a component contract is richer (a.k.a. more complex). When I
>>document a component I detail the assumptions the component has about
>>its context, the dependencies the component has on other services,
>>information concerning configuration options, and component specific
>>features. In all of these cases, meta constructs such as a <role/>,
>><name/>, <service/> can all be used to help make generated documentation
>>comprehensible.
>>
>>
>
>but is it related to this discussion?
>
>
Yes - because the meta-model I'm working with has an explicit attribute
detailing the role name and I very much want to apply that model to more
that just the deployment of a component by a container. That attribute
should not be polluted due to the requirements of one container type.
The important point is that we don't hide from this under a
"recommendation" but instead - deal with issue - figure out and
understand what is possible now and in the future.
>>[INFO ] (monster.brain.cognitive): role is a implementation concern
>>[INFO ] (monster.brain.cognitive): role != service class interface name
>>[INFO ] (monster.brain.cognitive): it's a slippery slope
>>[INFO ] (monster.brain.cognitive): Umm?
>>
>>
>
>it *is* a slippery slope, but we're already on it and climbing back to
>higher ground will mean we'll have to sever the chain binding us to some
>of our friends, meaning that they will tumble down the hill.
>
I'm not convinced of that at this time. I would really like to hear
from ECM and Fortress people about options. If I understand correctly,
Leo/2 thinks the dependency/role question can be handled within Fortress
- if that correct, this is at least lets us address ECM and consider the
possibility of enhancing ECM to provide something equivalent without
breaking anything that exists. This would be better for Avalon, and
better for the Cocoon community too.
>
>
>In how many of the existing containers do you want your components to
>work?
>
Today - 2.
Merlin and Phonix.
>How many of the existing components written for those containers
>that make the same slippery assumption as those containers do you want
>to work in future containers?
>
>
All of them (but I'm limiting by immediate scope to components that are
agnostic). But seriously - yes there are issues - and those issue need
to be treated as such, not pushed under the carpet with sweeping
"best-practice" statements. The issues are totally reasonable - the
whole notion of container interoperability is a new thing and we should
confront it honestly.
>>(who firmly believes that this is all orthogonal to the real issue of an
>>extendable framework meta-model that serves as the base-type for all
>>Avalon meta-models).
>>
>>
>
>yup.
>
>- Leo
>
>
:-)
Cheers, Steve,
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> we already apply restrictions in practice. The only container
> with a formal release, known to be in broad use (anyone knows
> how many results google gives for "cocoon hosting"?) is ECM,
> which applies these restrictions.
Nitpicking: Yes, but the release() method is in the CM interface,
so it is part of framework, and required for Pooled and SingleThreaded
components (to apply dispose(), stop(), etc.).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> There is also a part of me that just
> believes that this is a bad thing - maybe even a subtle evil - and yes,
> maybe I need a new brain because I haven't been able to come up with the
> clear definition of the issues. But I'll try again. First of all, lets
> scope this subject. When I'm talking about a role name I'm explicitly
> referring to the <role></role> meta element in a dependency descriptor
> as defined within the Merlin/Phoenix meta-model. This also means that by
> default the component will not work outside of that context.
>
> A dependency declaration:
>
> <dependency>
> <role>brain</role>
> <service name="org.apache.health.neural.CerebralMass" version="5.0.1"/>
> </dependency>
>
> The above dependency is declared within the scope of the component
> implementation. It is a name chosen by the component implementor to
> refer to the "service" declaration. First point of concern - a service
> declaration != interface class name.
no, but some current containers assume tight coupling, as do some
components.
> But lets move on. If I put myself
> in the position of a component - I know I'm going to
> managed/composed/assembled by a container that understands my dependency
> declaration, and I know that the information I have provided is
> sufficient for the container to know what name I will use to lookup the
> service that I need. I also know contractually that the container is not
> interpreting or applying any semantic magic relative to the name I
> supply. I know this because this is the way the framework works and my
> component is based on the framework contracts and documented semantics.
nope. As container behaviour is undefined in the framework, you cannot
be sure whether it does any interpretation. You'd have to check with the
container.
> My second point of concern is that I still have not received a concrete
> definition of why a role name "should" be linked to the interface class
> name.
there is no "should", except it is a convention already in place (like
our coding conventions, or the javabeans naming scheme), and it is a
convention that allows some clever stuff to happen inside ECM and
phoenix when a correct meta information definition is missing.
> Even if I were to apply this recommendation, my components would
> still be restricted to the Merlin/Phoenix meta-land.
but that we will fix, right?
> A third concern is
> more of fear that "we" simply slide from "recommending" an approach of
> "applying restrictions" - which is already been suggested.
we already apply restrictions in practice. The only container with a
formal release, known to be in broad use (anyone knows how many results
google gives for "cocoon hosting"?) is ECM, which applies these
restrictions.
> I
> fundamentally believe that these sort of actions will make the Avalon
> learning curve one notch higher that it already is.
yup.
> A forth concern is
> directly related to the clarity of component documentation. Unlike
> objects, a component contract is richer (a.k.a. more complex). When I
> document a component I detail the assumptions the component has about
> its context, the dependencies the component has on other services,
> information concerning configuration options, and component specific
> features. In all of these cases, meta constructs such as a <role/>,
> <name/>, <service/> can all be used to help make generated documentation
> comprehensible.
but is it related to this discussion?
> [INFO ] (monster.brain.cognitive): role is a implementation concern
> [INFO ] (monster.brain.cognitive): role != service class interface name
> [INFO ] (monster.brain.cognitive): it's a slippery slope
> [INFO ] (monster.brain.cognitive): Umm?
it *is* a slippery slope, but we're already on it and climbing back to
higher ground will mean we'll have to sever the chain binding us to some
of our friends, meaning that they will tumble down the hill.
In how many of the existing containers do you want your components to
work? How many of the existing components written for those containers
that make the same slippery assumption as those containers do you want
to work in future containers?
> (who firmly believes that this is all orthogonal to the real issue of an
> extendable framework meta-model that serves as the base-type for all
> Avalon meta-models).
yup.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 09:08 AM 6/12/2002 -0400, you wrote:
>
>> One point to consider. How many projects do you desire to use your
>> components with?
>
>
> Right. If you choose to break the pattern in use in the rest of avalon
> (which Stephens stuff does) then you are guarenteed that it will only
> work in phoenix and merlin atm (as they are the only ones that allow
> remapping of dependencies). ECM/Fortress/Myrmidon all map to classname
> directly (no ifs no buts) and Phoenix/Merlin encourages mapping to
> classname.
>
> The reason Stephen wants to use arbitrary strings is because he
> chooses to make the names meaningful and store metadata (he reuses the
> role name as name of logger, name of component etc). Personally I
> would encourage him to instead store it in attributes of dependency
> rather than in rolename/role designator.
Yes Merlin uses short roles names to assign to child logging category
names (which produces a really excellent and very predictable category
structure). This can be moved to a attribute of the dependency as I sort
out the meta management stuff (something currently in progress). But
that is not the whole story. There is also a part of me that just
believes that this is a bad thing - maybe even a subtle evil - and yes,
maybe I need a new brain because I haven't been able to come up with the
clear definition of the issues. But I'll try again. First of all, lets
scope this subject. When I'm talking about a role name I'm explicitly
referring to the <role></role> meta element in a dependency descriptor
as defined within the Merlin/Phoenix meta-model. This also means that by
default the component will not work outside of that context.
A dependency declaration:
<dependency>
<role>brain</role>
<service name="org.apache.health.neural.CerebralMass" version="5.0.1"/>
</dependency>
The above dependency is declared within the scope of the component
implementation. It is a name chosen by the component implementor to
refer to the "service" declaration. First point of concern - a service
declaration != interface class name. But lets move on. If I put myself
in the position of a component - I know I'm going to
managed/composed/assembled by a container that understands my dependency
declaration, and I know that the information I have provided is
sufficient for the container to know what name I will use to lookup the
service that I need. I also know contractually that the container is not
interpreting or applying any semantic magic relative to the name I
supply. I know this because this is the way the framework works and my
component is based on the framework contracts and documented semantics.
My second point of concern is that I still have not received a concrete
definition of why a role name "should" be linked to the interface class
name. Even if I were to apply this recommendation, my components would
still be restricted to the Merlin/Phoenix meta-land. A third concern is
more of fear that "we" simply slide from "recommending" an approach of
"applying restrictions" - which is already been suggested. I
fundamentally believe that these sort of actions will make the Avalon
learning curve one notch higher that it already is. A forth concern is
directly related to the clarity of component documentation. Unlike
objects, a component contract is richer (a.k.a. more complex). When I
document a component I detail the assumptions the component has about
its context, the dependencies the component has on other services,
information concerning configuration options, and component specific
features. In all of these cases, meta constructs such as a <role/>,
<name/>, <service/> can all be used to help make generated documentation
comprehensible. Take the following example - do the terms "heart" and
"brain" add to clarity of the specification?
Egore!
Go a find me a "brain" something from a dead professor, an academic,
even a politician. Then go and get me a "heart" - fresh and still
beating. When you've brought then back to me, we'll assemble the
monster!
<!-- from Monster.xinfo -->
<blockinfo>
<block>
<name>monster</name>
<version>3</version>
</block>
<dependencies>
<dependency>
<role>brain</role>
<service name="org.apache.health.neural.CerebralMass" version="5.0.1"/>
<dependency>
<dependency>
<role>heart</role>
<service name="org.apache.health.cardiac.Pump" version="2.4"/>
</dependency>
</dependencies>
</blockinfo>
[stuff happens]
[INFO ] (merlin): starting
[INFO ] (monster): waking up
[INFO ] (monster.heart): purging
[INFO ] (monster.heart): sustainable flow rate established
[INFO ] (monster.brain): bootstrapping cognitive processes
[INFO ] (monster.brain): cognitive processes established
[INFO ] (monster.brain.cognitive): role is a implementation concern
[INFO ] (monster.brain.cognitive): role != service class interface name
[INFO ] (monster.brain.cognitive): it's a slippery slope
[INFO ] (monster.brain.cognitive): Umm?
Cheers, Steve.
(who firmly believes that this is all orthogonal to the real issue of an
extendable framework meta-model that serves as the base-type for all
Avalon meta-models).
SJM.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 09:08 AM 6/12/2002 -0400, you wrote:
>One point to consider. How many projects do you desire to use your
>components with?
Right. If you choose to break the pattern in use in the rest of avalon
(which Stephens stuff does) then you are guarenteed that it will only work
in phoenix and merlin atm (as they are the only ones that allow remapping
of dependencies). ECM/Fortress/Myrmidon all map to classname directly (no
ifs no buts) and Phoenix/Merlin encourages mapping to classname.
The reason Stephen wants to use arbitrary strings is because he chooses to
make the names meaningful and store metadata (he reuses the role name as
name of logger, name of component etc). Personally I would encourage him to
instead store it in attributes of dependency rather than in rolename/role
designator.
BTW I agree using shortnames sucks imensly as I just went through suffering
as it had been done in myrmidon for some components and not in others. Erk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> One point to consider. How many projects do you desire to
> use your components with?
Many.
I understand the namespace clash you describe, but what I
propose in the referenced emails solve that by, for each
component, providing a unique role mapping.
Do this in your mind:
You have a list of components. Tag each one with a unique id.
Each component has a list of roles it will look up (dependencies).
Now, for each component, provide a map role->component id.
Done.
So, suppose LeosComponent looks for a source resolver at "resolver",
and StephensComponent looks for it at "source-resolver":
<component id="leo" class="LeosComponent">
<provide role="resolver" via="the-one-resolver"/>
</component>
<component id="stephen" class="StephensComponent">
<provide role="source-resolver" via="the-one-resolver"/>
</component>
<component id="the-one-resolver" class="SourceResolverImpl"/>
This also solves the problem where LeosComponent and StephensComponent
looks up the *same* role, say "source-resolver" but need *differently
configured* SourceResolvers:
<component id="leo" class="LeosComponent">
<provide role="source-resolver" via="leos-resolver"/>
</component>
<component id="stephen" class="StephensComponent">
<provide role="source-resolver" via="stephens-resolver"/>
</component>
<component id="leos-resolver" class="SourceResolverImpl"
basedir="/home/leo"/>
<component id="stephens-resolver" class="SourceResolverImpl"
basedir="/home/stephen"/>
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
One point to consider. How many projects do you desire to use your
components with?
Now, if your names are specified in the interface with MyComponent.ROLE,
then your component has nothing to worry about--but your interface does.
If in one project your SourceResolver is mapped to "resolver" and in
another project it is mapped to "source-resolver" (both valid under
Stephen's claims), then how do your components resolve that difference?
If you are set to lookup("resolver"), and then try to move the component
to the new project, it won't work because the correct mapping is
lookup("source-resolver"). If you specify a third-party interface like
Cocoon used to for managing role names, it has to be the *same* class.
That makes it difficult to change when you move from project to project.
But let's say Stephen uses the ROLE idiom, but ignores the interface
name
idiom--and Leo does the same thing. They both create a component with
the
ROLE name equal to "foobar", but they have incompatible interfaces.
Hmmm.
The idiom is not so much because it *could* be done other ways, but it
reduces the issues you have to worry about when you reuse components
between projects. ... Unless you like recompiling your components for
each project...
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Wednesday, June 12, 2002 4:27 AM
> To: 'Avalon Developers List'
> Subject: RE: [proposal] avalon 5 ComponentManager interface
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > While interface names may be convenient in the
> > majority of
> > cases - it is not definitive and any attempt to enforce the
> rule will
> > not only introduce unnecessarily constraints on a developer -
> > but will
> > also break existing components with more subtile role/service
> > relationship.
>
> Despite my saying that the role is an interface name, I have to
>
> + agree with Stephen.
>
> + wonder if this is not really a non-issue, with the container
> configuration containing the role -> individual component
> mappings (i.e. you specify in the configuration that when
> the component asks for X, it gets Y. So you can map
> the role "my.Store" or "my-store" to component "my.StoreImpl".):
>
http://marc.theaimsgroup.com/?l=avalon-dev&m=102266947408779&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102260094419459&w=2
+ Say that I still consider a (String,Object) lookup with hint
to be the best. Hint being defined as "if you ignore this,
processing can still continue (but the result may be a bit off)"
and role being "I need this to proceed". So "SSL" is a hint if
you'd *like* to have a SSL connection, but can do with any
connection. It is a role if you can not proceed (for whatever
reason) without a SSL connection.
The role is a String, becuase it is easy to load it from config
files. I tried completely opaque UID:s in my C++ impl of Avalon,
but ended up with the question - OK, so how do I specify this
in a config file? Hints, however, usually comes not from humans
but in the form of request objects etc., that are parsed by
selectors (or equiv.).
/LS
--
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: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> While interface names may be convenient in the
> majority of
> cases - it is not definitive and any attempt to enforce the rule will
> not only introduce unnecessarily constraints on a developer -
> but will
> also break existing components with more subtile role/service
> relationship.
Despite my saying that the role is an interface name, I have to
+ agree with Stephen.
+ wonder if this is not really a non-issue, with the container
configuration containing the role -> individual component
mappings (i.e. you specify in the configuration that when
the component asks for X, it gets Y. So you can map
the role "my.Store" or "my-store" to component "my.StoreImpl".):
http://marc.theaimsgroup.com/?l=avalon-dev&m=102266947408779&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102260094419459&w=2
+ Say that I still consider a (String,Object) lookup with hint
to be the best. Hint being defined as "if you ignore this,
processing can still continue (but the result may be a bit off)"
and role being "I need this to proceed". So "SSL" is a hint if
you'd *like* to have a SSL connection, but can do with any
connection. It is a role if you can not proceed (for whatever
reason) without a SSL connection.
The role is a String, becuase it is easy to load it from config
files. I tried completely opaque UID:s in my C++ impl of Avalon,
but ended up with the question - OK, so how do I specify this
in a config file? Hints, however, usually comes not from humans
but in the form of request objects etc., that are parsed by
selectors (or equiv.).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Pete:
Your summary is mixing two separate concerns:
1. the concern related to key management
The key management issue is address by apply the convention
of public static final String KEY = "some-opaque-value". This
ensures that components can apply a consistent usage pattern
when referencing key values in code. This is orthogonal
to the question of the actual string value.
The usage is KEY is a valid best practice that can be
validated and/or enforced and is consistent with the framework
usage.
2. the concern related to ECM
ECM uses the role name together with some implementation
magic to support resolution of services exposed under the
component manager interface. In this context, the association
of an interface name as a key value is consistent with the
design of ECM.
This may be a valid best practice within the scope of ECM
but it is inconsistent with the specifications at the framework
level.
Attempt at enforcing the "principal" that a key corresponds to an
interface effectively negates the potential for multiple service
provision where a interface is shared by more than one provided service
(without resorting to implementation workarounds such as a component
selector). This is simply because keys are dealing with "instances" of
services that a component implementation requires. Interface names are
"type" level. While interface names may be convenient in the majority of
cases - it is not definitive and any attempt to enforce the rule will
not only introduce unnecessarily constraints on a developer - but will
also break existing components with more subtile role/service relationship.
Cheers, Steve.
p.s. sins concerning metainfo back-pointers are forgiven
- a solution has emerged :-)
Peter Donald wrote:
>Roles as interface Pattern
>--------------------------
>We have pretty much always used this since day 1 (or at least since I been
>here). The main reason is that it allows a cleaner separation between
>interface and implementation and easier classloader management if we need to
>separate the two concepts. Phoenix enforces this and I believe ECM may
>aswell?
>
>Role Names as ClassName + "/somekey"
>------------------------------------
>This was established after we ran into trouble maintaining keys. ie We had
>changed the rolename in container but forgot to update the components or vice
>versa. After this happened a few times we decided to standardize on name of
>class. However a couple of times we broke cocoon because we moved components
>without updating their role strings. So now we recomend that you have the
>Role name auotmatically maintained via
>
>String ROLE = MyClass.class.getName();
>
>That way you always know what it will be and it will only change when you move
>class (which requires a recompile of all the classes anyways).
>
>The practice of psostfixing it with "/someKey" was arbitarily chosen. The "/"
>was chosen as then you could validate the best practice of using
>rolename=classname however the key part is an arbitary string.
>
>It is true that no container actually enforces this but Phoenix does make it
>easier if you follow this pattern. ie You don't have to declare <role/> if it
>matches service name. In the future it may also issue warning if role names
>don't match pattern. (Had a request for that but forgot to implement it).
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
Roles as interface Pattern
--------------------------
We have pretty much always used this since day 1 (or at least since I been
here). The main reason is that it allows a cleaner separation between
interface and implementation and easier classloader management if we need to
separate the two concepts. Phoenix enforces this and I believe ECM may
aswell?
Role Names as ClassName + "/somekey"
------------------------------------
This was established after we ran into trouble maintaining keys. ie We had
changed the rolename in container but forgot to update the components or vice
versa. After this happened a few times we decided to standardize on name of
class. However a couple of times we broke cocoon because we moved components
without updating their role strings. So now we recomend that you have the
Role name auotmatically maintained via
String ROLE = MyClass.class.getName();
That way you always know what it will be and it will only change when you move
class (which requires a recompile of all the classes anyways).
The practice of psostfixing it with "/someKey" was arbitarily chosen. The "/"
was chosen as then you could validate the best practice of using
rolename=classname however the key part is an arbitary string.
It is true that no container actually enforces this but Phoenix does make it
easier if you follow this pattern. ie You don't have to declare <role/> if it
matches service name. In the future it may also issue warning if role names
don't match pattern. (Had a request for that but forgot to implement it).
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>>Berin Loritsch wrote:
>>>
>>>
>>>
>>>>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>>>>
>>>>>Leo Sutic wrote:
>>>>>
>>>>>
>>>>>
>>>>>>The need for hints exist because we have decided that the
>>>>>>
>>>>>>
>>>role should
>>>
>>>
>>>>>>be an interface name.
>>>>>>
>>>>>>
>>>>>>
>>>>>Slowdown here - can anyone/someone please refer me to any Avalon
>>>>>framework documentation anywhere that states a role is an interface
>>>>>name? Please - let's not get mixed up between decisions
>>>>>concerning ECM.
>>>>>The CM/SM is not and does not inherit from ECM.
>>>>>
>>>>>
>>>>It's a decision we came to a long time ago.
>>>>
>>>>
>>>>
>>>-1
>>>
>>>The "decision" is not documented in the CM/SM interfaces - is not
>>>enforced by anything in the framework least of all
>>>DefaultComponentManager or DefaultServiceManager. But the
>>>worst thing
>>>of all is that implies the potential interpritation of the
>>>lookup key on
>>>a CM/SM manager implemetation. The decision I accept is the decision
>>>expressed by the CM/SM interfaces and the javadoc that goes with them.
>>>
>>>
>>Steve, with all do respect, I do not know what your "-1" is supposed
>>to signify. The fact that it isn't properly represented in the javadocs
>>documentation doesn't negate the fact that historically the team came
>>to that conclusion. It does not negate the fact that it was the
>>tradition imposed by Federico, who convinced both Peter and I (no small
>>feat I might add) that it was the best way.
>>
>>
>
>It is a tradition, a recommendation, and a "best practice". It is _not_
>a requirment.
>
I have to question this "best practice". It is completely possible for
a component to maintain its own role namespace which is a fundamental
characteristic if your doing any sort of complex system. Furthermore
nobody has provided a rationale for this beyond "a tradition imposed by
Federico" which just does not stack-up. A best practice is normally
founded on rationle that is defensible. The only rationale that can be
infurred is the association to ECM patterns of usage and I don't think
ECM represents best-practice.
>>enforces the role abstraction. The important thing is that the Role is
>>tightly coupled to its interface--and as such the lookup name should be
>>the Role's interface name.
>>
>>
>
>The important thing is that the Role is tightly coupled to its
>interface--and as such the lookup name should be tightly coupled to the
>Role's interface name.
>
>important difference.
>
>We could tighten this to the lookup name should start with the results
>of getClass().toString() called on the role interface, minus the
>starting "interface ".
>
>
This would introduce an artifical and unnecessary limitation?
Here is an implementation approach that does not mix the lookup key with
the service/component that is returned.
<dependency>
<role>something-basic</role>
<service name="org.apache.excalibur.assembly.demo.BasicService"/>
</dependency>
There is no ambiguity here - the service dependecy is clearly started
and completely consistent with a component centric management of a role
namespace.
>
>
>>The decision stems from the best way to have a unique name for a role,
>>without being subject to naming clashes. It would be really bad and
>>incorrect if I received a component implementing
>>"com.infoplanning.Store"
>>when I really wanted something implementing
>>"org.apache.excalibur.Store".
>>If the role name in the CM was simply "Store", which one should the
>>container
>>return? Under which circumstances should it return the
>>"com.infoplanning"
>>version and which circumstances should it return the
>>"org.apache.excalibur"
>>version?
>>
>>
>
>this is determined by the combination of container programmer (design
>time) and assembler (initialization time) (just to answer the question
>for those that might not know the answer).
>
Agreed.
>
>
>In the case of phoenix, it depends on the xml configuration files fed
>into it by the assembler.
>
Which is an approach that can be used outside of Phonix in the runtime
creation of service by a container when servicing/composing its
services/components.
>>Would you rather set up an authority to come up with id's like ICANN?
>>
>>
>
>ugh. The thing both sun and w3 figured out is that basing yourself on
>ICANN id's is the only way to fly =)
>
>You forget the other alternative allowed (regardless of whether this is
>by code or contract) is for framework users to be their own authority.
>
The scalable approach is for the component to manage its own role
namespace (through a clean seperation of lookup role and the
computational dependecy).
>final note: coupling role name to interface only gives as much namespace
>clash avoidance as the java namespace mechanism, which still depends on
>trust (unless you use signed jars). I'd suggest not trying making it
>more solid.
>
>- Leo, who always follows "best practice" in his own projects
>
>
Steve - who tends question and understand why something is a best
practice before following.
:-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > Berin Loritsch wrote:
> >
> > >>From: Stephen McConnell [mailto:mcconnell@osm.net]
> > >>
> > >>Leo Sutic wrote:
> > >>
> > >>>The need for hints exist because we have decided that the
> > role should
> > >>>be an interface name.
> > >>>
> > >>Slowdown here - can anyone/someone please refer me to any Avalon
> > >>framework documentation anywhere that states a role is an interface
> > >>name? Please - let's not get mixed up between decisions
> > >>concerning ECM.
> > >> The CM/SM is not and does not inherit from ECM.
> > >
> > >It's a decision we came to a long time ago.
> > >
> > -1
> >
> > The "decision" is not documented in the CM/SM interfaces - is not
> > enforced by anything in the framework least of all
> > DefaultComponentManager or DefaultServiceManager. But the
> > worst thing
> > of all is that implies the potential interpritation of the
> > lookup key on
> > a CM/SM manager implemetation. The decision I accept is the decision
> > expressed by the CM/SM interfaces and the javadoc that goes with them.
>
> Steve, with all do respect, I do not know what your "-1" is supposed
> to signify. The fact that it isn't properly represented in the javadocs
> documentation doesn't negate the fact that historically the team came
> to that conclusion. It does not negate the fact that it was the
> tradition
> imposed by Federico, who convinced both Peter and I (no small feat I
> might
> add) that it was the best way.
It is a tradition, a recommendation, and a "best practice". It is _not_
a requirment.
JDBC specifies a JDBC url starts with "jdbc:", then recommends you
follow with "drivervendor:host:port:database:{settings}". It will still
work if you do it differently, and that's cool.
> enforces the role abstraction. The important thing is that the Role is
> tightly coupled to its interface--and as such the lookup name should be
> the Role's interface name.
The important thing is that the Role is tightly coupled to its
interface--and as such the lookup name should be tightly coupled to the
Role's interface name.
important difference.
We could tighten this to the lookup name should start with the results
of getClass().toString() called on the role interface, minus the
starting "interface ".
> The decision stems from the best way to have a unique name for a role,
> without being subject to naming clashes. It would be really bad and
> incorrect if I received a component implementing
> "com.infoplanning.Store"
> when I really wanted something implementing
> "org.apache.excalibur.Store".
> If the role name in the CM was simply "Store", which one should the
> container
> return? Under which circumstances should it return the
> "com.infoplanning"
> version and which circumstances should it return the
> "org.apache.excalibur"
> version?
this is determined by the combination of container programmer (design
time) and assembler (initialization time) (just to answer the question
for those that might not know the answer).
In the case of phoenix, it depends on the xml configuration files fed
into it by the assembler.
> Would you rather set up an authority to come up with id's like ICANN?
ugh. The thing both sun and w3 figured out is that basing yourself on
ICANN id's is the only way to fly =)
You forget the other alternative allowed (regardless of whether this is
by code or contract) is for framework users to be their own authority.
final note: coupling role name to interface only gives as much namespace
clash avoidance as the java namespace mechanism, which still depends on
trust (unless you use signed jars). I'd suggest not trying making it
more solid.
- Leo, who always follows "best practice" in his own projects
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal wrote:
>On Tuesday 11 June 2002 09:27 am, Berin Loritsch wrote:
>
>
>>The decision stems from the best way to have a unique name for a role,
>>without being subject to naming clashes. It would be really bad and
>>
>>
>
>I've always viewed it as a "best practices" method for naming roles. Roles
>don't *have* to be named after their interfaces but its easy enough to do and
>makes sense.
>
>imho, Stephan was balking at "role name == interface name" as a concrete
>truth for Avalon Framework. Its not, its just highly recommended.
>-pete
>
>
Actually, I'm balking at both!
The notion of "highly recommended" seems to me to be simply an unfounded
recommendation - it's subtle reinforcement that this "best practice". I
do not see any grounds for declaring this a "best practice" - in fact I
believe it is the opposite!
Roles (at the level of abstraction of the framework) are unique within
the scope of the component that declares them. It's simply that simple.
This issue is that a "best practice" or the classification of something
as "highly recommended" contributes to the belief that role names are
more than simple strings, unique within the scope of a particular
component type that are used for nothing more than an opaque key to a
service instance. Diverging from opaque keys without rigorouse
supporting semantics is just plain "bad". I would accept that "we" have
"traditionally" used the convention of interface class name for a role
name but as we all know - "tradition" does not mean "best practice", no
matter how highly recommended a particular tradition is said to be.
The real "best-practice" is for a component to manage its own namespace.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 11 June 2002 09:27 am, Berin Loritsch wrote:
> The decision stems from the best way to have a unique name for a role,
> without being subject to naming clashes. It would be really bad and
I've always viewed it as a "best practices" method for naming roles. Roles
don't *have* to be named after their interfaces but its easy enough to do and
makes sense.
imho, Stephan was balking at "role name == interface name" as a concrete
truth for Avalon Framework. Its not, its just highly recommended.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Berin Loritsch wrote:
>
> >>From: Stephen McConnell [mailto:mcconnell@osm.net]
> >>
> >>Leo Sutic wrote:
> >>
> >>
> >>
> >>>The need for hints exist because we have decided that the
> role should
> >>>be an interface name.
> >>>
> >>>
> >>>
> >>Slowdown here - can anyone/someone please refer me to any Avalon
> >>framework documentation anywhere that states a role is an interface
> >>name? Please - let's not get mixed up between decisions
> >>concerning ECM.
> >> The CM/SM is not and does not inherit from ECM.
> >>
> >>
> >
> >Developing with Avalon?
> >
> >It's a decision we came to a long time ago.
> >
> -1
>
> The "decision" is not documented in the CM/SM interfaces - is not
> enforced by anything in the framework least of all
> DefaultComponentManager or DefaultServiceManager. But the
> worst thing
> of all is that implies the potential interpritation of the
> lookup key on
> a CM/SM manager implemetation. The decision I accept is the decision
> expressed by the CM/SM interfaces and the javadoc that goes with them.
>
> Cheers, Steve.
Steve, with all do respect, I do not know what your "-1" is supposed
to signify. The fact that it isn't properly represented in the javadocs
documentation doesn't negate the fact that historically the team came
to that conclusion. It does not negate the fact that it was the
tradition
imposed by Federico, who convinced both Peter and I (no small feat I
might
add) that it was the best way.
With this restriction, I looked at ways of programatically enforcing the
Role to be the interface class, or something more concrete.
Unfortunately,
the interface class won't work because of classloader issues (if a class
is loaded in separate classloaders, it is considered to be a different
class). And I have not been able to come up with an agreeable object
that
enforces the role abstraction. The important thing is that the Role is
tightly coupled to its interface--and as such the lookup name should be
the Role's interface name.
The decision stems from the best way to have a unique name for a role,
without being subject to naming clashes. It would be really bad and
incorrect if I received a component implementing
"com.infoplanning.Store"
when I really wanted something implementing
"org.apache.excalibur.Store".
If the role name in the CM was simply "Store", which one should the
container
return? Under which circumstances should it return the
"com.infoplanning"
version and which circumstances should it return the
"org.apache.excalibur"
version? The reality is that they are separate roles.
Would you rather set up an authority to come up with id's like ICANN?
The "-1" doesn't change a decision already made--with good reason. All
it
might do is inspire us to document it in the Javadocs.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>
>>Leo Sutic wrote:
>>
>>
>>
>>>The need for hints exist because we have decided that the
>>>role should be an interface name.
>>>
>>>
>>>
>>Slowdown here - can anyone/someone please refer me to any Avalon
>>framework documentation anywhere that states a role is an interface
>>name? Please - let's not get mixed up between decisions
>>concerning ECM.
>> The CM/SM is not and does not inherit from ECM.
>>
>>
>
>Developing with Avalon?
>
>It's a decision we came to a long time ago.
>
-1
The "decision" is not documented in the CM/SM interfaces - is not
enforced by anything in the framework least of all
DefaultComponentManager or DefaultServiceManager. But the worst thing
of all is that implies the potential interpritation of the lookup key on
a CM/SM manager implemetation. The decision I accept is the decision
expressed by the CM/SM interfaces and the javadoc that goes with them.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Leo Sutic wrote:
>
> >
> >The need for hints exist because we have decided that the
> >role should be an interface name.
> >
>
> Slowdown here - can anyone/someone please refer me to any Avalon
> framework documentation anywhere that states a role is an interface
> name? Please - let's not get mixed up between decisions
> concerning ECM.
> The CM/SM is not and does not inherit from ECM.
Developing with Avalon?
It's a decision we came to a long time ago.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Sutic wrote:
>
>The need for hints exist because we have decided that the
>role should be an interface name.
>
Slowdown here - can anyone/someone please refer me to any Avalon
framework documentation anywhere that states a role is an interface
name? Please - let's not get mixed up between decisions concerning ECM.
The CM/SM is not and does not inherit from ECM.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Summary:
>
> - proposal for component management in avalon 5:
> 1) removal of ComponentSelector
> 2) removal of release()
Without including in the proposal a replacement for CS when it
operates on Objects (such as when selecting components based
on a ServletRequest), and a replacement for release() that can
handle switching between pooled and non-pooled components without
any changes to the client code, I can not vote for this proposal.
------------------------
All ComponentManagers should support hints, or none. We're not
making the developers any favors by introducing yet another
"this should work, but then again it might not". A good explanation
of why this is bad exists at:
http://www.lurkertech.com/linuxvideoio.html
"If a video I/O API does not offer a common set of scales,
formats, aspects, and crops which are guaranteed to work on
all devices, you can have all the query mechanisms in the
world but it does an app no good. Think about it -- what
is the app supposed to do when you plant it on a machine
which supports only some new format? Spontaneously sprout
new code to handle the format?"
The need for hints exist because we have decided that the
role should be an interface name. To specify more, we can
tack stuff on to the interface name (MyComponent.ROLE +
"/somehint/anotherhint"), but I consider that uglier than
allowing for a separate hint parameter.
Also, with just String hints, if you use a ServletRequest as
hint, you end up with:
lookup (role, stringifyRequest (request))
I have no problem with the role being a String, and the hint
being an Object, as we have fixed the role to be an interface
name (and thus a String), while we have not fixed the hint in
the same way.
------------------------
The
if (exists (role)) manager.lookup (role)
construct should only be required when the role you are looking
up is optional. That is, the exists() call works just like
hasComponent(). (This would be similar to the use of
FileNotFoundException - if you are uncertain whether the file exists
you should call exists() before opening, but if it is required
to exist, you can just try to open it.) I question the assertion
that the use of exists() as you propose is common java practice.
I also question that it results in more performant code, as you
do not pay for exceptions unless they are thrown (See
http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
for exception handling.) - thus you have traded a lookup that
should not fail except in exceptional circumstances for a check
*and* a lookup.
Please justify these assumptions.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
my 2 cents worth...
Peter Donald wrote:
> >role+hint is *not* a simple way of declaring role="base+hint"
> >
> >Role: what do do
> >Hint: *how* to do it
>
> I would not say that. I would say
>
> Role: arbitrary name indicating a dependency
> Hint: metainfo associated with dependency indicating a possible policy for
> selecting from candidate providers.
I've always thought of it as something like:
role: what I want the component to do.
hint: purpose for which I want the component.
I thought the hint was for when the component was going to request several
components of the same role but for different purposes.
shouldn't the 'how' part should be completely up to the whim of the
assembler...
e.g. is it appropiate to use the hint to request an "ssl" connection? the
assembler might have put the server you are connecting to on the same
machine making ssl unecessary, however if you request a connection for the
purpose of "military-secrets" the assembler should make sure this
connection is secure.
hence: I'd be in favour of renaming 'hint' to 'purpose'.
====
also to reduce the confusion in determining what a role means, would it be
reasonable to declare that a role *must* be an interface name? And if you
want a sub-role then you should subclass the interface (the subclass
doesn't have to have any extra methods).
[would/could this work for cocoon?]
You'd probably also need to do a bit more work in the container -- e.g. if
I request an component with role SomeInterface, I might get back a
component implementing SubClassOfSomeInterface.
====
does this "interface + purpose" approach satisfy all the use cases?
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Monday 17 June 2002 07:39 am, Nicola Ken Barozzi wrote:
> >> Role: arbitrary name indicating a dependency
> >> Hint: metainfo associated with dependency indicating a possible policy
> >> for selecting from candidate providers.
> >
> > ++++++++++++++++++++++++++++++++++++++++++++1
>
> Tell me how to use flat roles in Cocoon.
> Tell me.
The ComponentSelector notion is removed from the core aspect of Framework.
For Cocoon's use, when you need a transformer you get a TransformerManager
that handles the pooling and individual transformers.
There are 2 issues that impact cocoon:
1) No hints
2) Returning thread-safe components
Its a simple migration because you basically go from ComponentSelector ->
TransformerManager
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Peter, you still haven't addressed the scenario #5 from the
COmponentManager
use case thread.
How do you propose to do it?
And don't tell me write a XXXManager component--what difference is
between
that and the ComponentSelector?
Please, enlighten me.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Monday, June 17, 2002 6:55 PM
> To: Avalon Developers List
> Subject: Re: [proposal] avalon 5 ComponentManager interface
>
>
> At 11:10 PM 6/17/2002 +0200, you wrote:
> > > Hmm ... considering you have described an architecture
> that solves
> > > this this sounds like bandstanding. A4 is here to stay then.
> >
> >I don't get it.
> >
> >Are you saying that you'd like to throw away the entire A5 concept
> >because of
> >
> > lookup(role,hint)
>
> largely. If A5 is to exist it should correct all known
> problems. One of the
> biggest problems has arisen because people have been misusing avalon
> interfaces. Hint is metadata associated with a dependency -
> you still have
> not answered why you feel the need to place metadata in both code and
> configuration files?
>
> Remember that there was once a belief that ThreadSafe and
> other marker
> interfaces were "absolutely essential" for a scalable system.
> Now they are
> considered a hack because they put metadata into both code
> and descriptors.
> Note that ComponentSelectors are now also considered a hack -
> partially
> because they put metadata in both code and descriptors.
> Finally there is
> the Component interface - it is now considered a hack as it
> puts metadata
> in both code and descriptors. This is not to mention all
> those other things
> that I managed to win (Poolable + Recyclable are not in
> framework, ECM is
> not in framework etc) who commit similar crimes.
>
> Note that each of these features (except Component) were considered
> "absolutely essential" features and without them Cocoon would
> be crippled,
> the sky would fall and blah blah blah. I pointed out back
> then that they
> are going to limit scalability and adversly effect
> maintainability but I
> was told I was wrong. However it turns out that Cocoon
> developers later
> came to the same conclusion that I did and more than one has
> blamed Avalon
> for the problems where the fault really lies with Cocoon
> developers. Don't
> be blinded by current implementation strategy or else the
> same thing will
> occur again in another 6 months.
>
> >where we *explicitly* state that the container is safely allowed to
> >ignore the hint?
>
> because some will not ignore the writing because they see
> containers such
> as cocoon ignoring the writing. Cocoon already treats hints
> as constraints
> and not hints - I cant see that as changing because the
> concept is not
> clear or simple. Even Berin has confused the issue a couple
> of times and
> presumably he knows what he is talking about.
>
>
> Cheers,
>
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
> - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@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: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 11:10 PM 6/17/2002 +0200, you wrote:
> > Hmm ... considering you have described an architecture that solves this
> > this sounds like bandstanding. A4 is here to stay then.
>
>I don't get it.
>
>Are you saying that you'd like to throw away the entire A5 concept
>because of
>
> lookup(role,hint)
largely. If A5 is to exist it should correct all known problems. One of the
biggest problems has arisen because people have been misusing avalon
interfaces. Hint is metadata associated with a dependency - you still have
not answered why you feel the need to place metadata in both code and
configuration files?
Remember that there was once a belief that ThreadSafe and other marker
interfaces were "absolutely essential" for a scalable system. Now they are
considered a hack because they put metadata into both code and descriptors.
Note that ComponentSelectors are now also considered a hack - partially
because they put metadata in both code and descriptors. Finally there is
the Component interface - it is now considered a hack as it puts metadata
in both code and descriptors. This is not to mention all those other things
that I managed to win (Poolable + Recyclable are not in framework, ECM is
not in framework etc) who commit similar crimes.
Note that each of these features (except Component) were considered
"absolutely essential" features and without them Cocoon would be crippled,
the sky would fall and blah blah blah. I pointed out back then that they
are going to limit scalability and adversly effect maintainability but I
was told I was wrong. However it turns out that Cocoon developers later
came to the same conclusion that I did and more than one has blamed Avalon
for the problems where the fault really lies with Cocoon developers. Don't
be blinded by current implementation strategy or else the same thing will
occur again in another 6 months.
>where we *explicitly* state that the container is safely allowed to
>ignore the hint?
because some will not ignore the writing because they see containers such
as cocoon ignoring the writing. Cocoon already treats hints as constraints
and not hints - I cant see that as changing because the concept is not
clear or simple. Even Berin has confused the issue a couple of times and
presumably he knows what he is talking about.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 02:22 PM 6/17/2002 +0200, you wrote:
> > > From: Stephen McConnell [mailto:mcconnell@osm.net]
> > >
> > > Does that make sence?
> > > If not - what are the pieces that are missing?
> >
> >You can not pre-build the map as you say. The mappings change
> >at runtime. Sure, you can recompute the map all the time, but
> >why would Cocoon use Avalon then, if they have to do all the
> >framework stuff themselves?
> >
> >Take my word for it Stephen, we need hints.
> >
> >I *hate* to put it this way, but it is true: A lot of thought
> >has gone into the concept of using hints, Cocoon uses hints
> >*exactly* as they were supposed to be used, and there is no more
> >elegant solution. I can give you the requirements for Cocoon, and
> >you can say "well, but..." and come up with a solution that does not
> >use hints, but that solution will be (a) uglier (b) reduce the
> >usability of Avalon for Cocoon, meaning that Cocoon will not use A5
> >and thus also be (c) utterly worthless in practice, although fine in
> >theory. In short, a waste of our precious time for *both* of us.
> >As Stefano said, mapping a 2d set to a 1d set is always
> >possible, but in this context it is only of academic value.
>
> Hmm ... considering you have described an architecture that solves this
> this sounds like bandstanding. A4 is here to stay then.
I don't get it.
Are you saying that you'd like to throw away the entire A5 concept
because of
lookup(role,hint)
where we *explicitly* state that the container is safely allowed to
ignore the hint?
Please, tell me why.
In case you answer with 'because we could have N-dimensional lookup
constraints', then I question you just like Leo (LS) did: shouldn't it
become
lookup(query)
then?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> Hmm ... considering you have described an architecture that
> solves this
> this sounds like bandstanding. A4 is here to stay then.
My architecture solves the case where the wiring can be done
at assembly-time, it does not "solve" the Cocoon use case, except
when it is used together with ComponentSelectors (which I envisioned
it would be).
The big idea was for it to solve some cases where you in A4 had to
use ROLE + "/something". *Not* as a replacement for hints and
component selectors.
I'll do a proper writeup of exactly what it is I have in mind, and
what use cases it solves.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 02:22 PM 6/17/2002 +0200, you wrote:
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > Does that make sence?
> > If not - what are the pieces that are missing?
>
>You can not pre-build the map as you say. The mappings change
>at runtime. Sure, you can recompute the map all the time, but
>why would Cocoon use Avalon then, if they have to do all the
>framework stuff themselves?
>
>Take my word for it Stephen, we need hints.
>
>I *hate* to put it this way, but it is true: A lot of thought
>has gone into the concept of using hints, Cocoon uses hints
>*exactly* as they were supposed to be used, and there is no more
>elegant solution. I can give you the requirements for Cocoon, and
>you can say "well, but..." and come up with a solution that does not
>use hints, but that solution will be (a) uglier (b) reduce the
>usability of Avalon for Cocoon, meaning that Cocoon will not use A5
>and thus also be (c) utterly worthless in practice, although fine in
>theory. In short, a waste of our precious time for *both* of us.
>As Stefano said, mapping a 2d set to a 1d set is always
>possible, but in this context it is only of academic value.
Hmm ... considering you have described an architecture that solves this
this sounds like bandstanding. A4 is here to stay then.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
> My impression is that your assuming I'm talking about something else.
> I'm not discounting the requirements for a client to supply constraints
> and/or context to a container. I am disputing the approach of packing
> this into the lookup operation.
Could you please supply me with an example of how to do this?
I can't imagine one 8-|
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Extensions to Avalon containers (was: RE: [proposal] avalon 5 ComponentManager interface)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo, please state how your approach would work for the
> use cases I outlined in my other message.
I'll get to that in another proposal (typing it up right now).
Basically I consider this orthogonal, and I'll show how
it can be made to work with hints.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Extensions to Avalon containers (was: RE: [proposal] avalon 5 ComponentManager interface)
Posted by Berin Loritsch <bl...@apache.org>.
Leo, please state how your approach would work for the
use cases I outlined in my other message.
Please ignore the releasing of components for the time being,
as that is not what we are discussing ATM.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Monday, June 17, 2002 2:45 PM
> To: 'Avalon Developers List'
> Subject: Extensions to Avalon containers (was: RE: [proposal]
> avalon 5 ComponentManager interface)
>
>
> All,
>
> I've repeatedly stated that I have a proposal regarding the
> lookup of components - although I have not really specified
> what that proposal is. The result is that I have sometimes
> even apparently argued against myself.
>
> What I propose is in all simplicity this: The ability to
> define a component specific namespace in the container as far
> as roles are concerned.
>
> That didn't make much sense, but let's look at an example.
> This is the situation in most containers now:
>
> <component role="my.Role" class="MyComponent"/>
>
> <component role="ConnectionManager" class="some.ConnectionManager"/>
>
> All roles, defined for all components in the container,
> exist in a single, flat namespace. You can not have two
> implementations of the same role, without either using
> selectors, or by qualifying the role name. For example, the
> ConnectionManager.ROLE + "/SSL" sample.
>
> There is also a problem that appears when you mix
> components from different origins: Suppose you have
> a component called MyComponent. Then you download from
> some website a needed component called OtherComponent.
>
> Both MyComponent and OtherComponent are composers. Both
> require a ConnectionManager, which they use
> ConnectionManager.ROLE to lookup.
>
> The problem: They want *different* connection managers,
> and neither uses a component selector.
>
> <component role="my.Role" class="MyComponent"/>
>
> <component role="ConnectionManager" class="some.ConnectionManager"/>
>
> <component role="other.Role" class="OtherComponent"/>
>
> <!-- DOESN'T WORK! Collides with some.ConnectionManager. -->
> <component role="ConnectionManager"
> class="some.other.ConnectionManager"/>
>
> So how are you going to solve this? In the current ECM, you
> can't. For each role, there may be a single implementation.
> If you want more, you have to use component selectors.
>
> Another problem: As above, but you want MyComponent and
> OtherComponent to use the *same* connection manager. This
> time, however, OtherComponent looks up "connection-manager"
> and MyComponent looks up "ConnectionManager". So what's the role?
>
> My proposal is that for each component in a container, you
> can optionally specify new role mappings. The first problem above
> would be solved by:
>
> <component role="my.Role" class="MyComponent">
> <provide role="ConnectionManager" via="ConnectionManager/some"/>
> </component>
>
> <component role="ConnectionManager/some"
> class="some.ConnectionManager"/>
>
> <component role="other.Role" class="OtherComponent">
> <provide role="ConnectionManager" via="ConnectionManager/other"/>
> </component>
>
> <!-- WORKS! No collision any more. -->
> <component role="ConnectionManager/other"
> class="some.other.ConnectionManager"/>
>
> The second by:
>
> <!-- There is no need to provide a mapping for MyComponent,
> as it will lookup "ConnectionManager", which is a valid
> role name in the container namespace. -->
> <component role="my.Role" class="MyComponent"/>
>
> <component role="ConnectionManager" class="some.ConnectionManager"/>
>
> <component role="other.Role" class="OtherComponent">
> <!-- Uses the same connection manager as MyComponent, despite
> looking up a different role string. -->
> <provide role="connection-manager" via="ConnectionManager"/>
> </component>
>
> That is all.
>
> This functionality already exists in Phoenix, if I understand
> it correctly, and can be put into Fortress ( = Phortress? :))
> without breaking backwards compatibility.
>
> This does not solve the "what is a hint" problem, it does not
> solve runtime mappings for Cocoon. It only solves the
> namespace collision issues. (Note that I *will* take credit
> for solving those if someone can extract a working solution
> from the above. ;) "Oh, yeah, but that was what I said all along..." )
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@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>
Extensions to Avalon containers (was: RE: [proposal] avalon 5 ComponentManager interface)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
All,
I've repeatedly stated that I have a proposal regarding the
lookup of components - although I have not really specified what
that proposal is. The result is that I have sometimes even apparently
argued against myself.
What I propose is in all simplicity this: The ability to define
a component specific namespace in the container as far as
roles are concerned.
That didn't make much sense, but let's look at an example.
This is the situation in most containers now:
<component role="my.Role" class="MyComponent"/>
<component role="ConnectionManager" class="some.ConnectionManager"/>
All roles, defined for all components in the container,
exist in a single, flat namespace. You can not have two
implementations of the same role, without either using
selectors, or by qualifying the role name. For example,
the ConnectionManager.ROLE + "/SSL" sample.
There is also a problem that appears when you mix
components from different origins: Suppose you have
a component called MyComponent. Then you download from
some website a needed component called OtherComponent.
Both MyComponent and OtherComponent are composers. Both
require a ConnectionManager, which they use ConnectionManager.ROLE
to lookup.
The problem: They want *different* connection managers,
and neither uses a component selector.
<component role="my.Role" class="MyComponent"/>
<component role="ConnectionManager" class="some.ConnectionManager"/>
<component role="other.Role" class="OtherComponent"/>
<!-- DOESN'T WORK! Collides with some.ConnectionManager. -->
<component role="ConnectionManager"
class="some.other.ConnectionManager"/>
So how are you going to solve this? In the current ECM, you can't.
For each role, there may be a single implementation. If you
want more, you have to use component selectors.
Another problem: As above, but you want MyComponent and OtherComponent
to use the *same* connection manager. This time, however, OtherComponent
looks up "connection-manager" and MyComponent looks up
"ConnectionManager".
So what's the role?
My proposal is that for each component in a container, you can
optionally specify new role mappings. The first problem above
would be solved by:
<component role="my.Role" class="MyComponent">
<provide role="ConnectionManager" via="ConnectionManager/some"/>
</component>
<component role="ConnectionManager/some"
class="some.ConnectionManager"/>
<component role="other.Role" class="OtherComponent">
<provide role="ConnectionManager" via="ConnectionManager/other"/>
</component>
<!-- WORKS! No collision any more. -->
<component role="ConnectionManager/other"
class="some.other.ConnectionManager"/>
The second by:
<!-- There is no need to provide a mapping for MyComponent,
as it will lookup "ConnectionManager", which is a valid
role name in the container namespace. -->
<component role="my.Role" class="MyComponent"/>
<component role="ConnectionManager" class="some.ConnectionManager"/>
<component role="other.Role" class="OtherComponent">
<!-- Uses the same connection manager as MyComponent, despite
looking up a different role string. -->
<provide role="connection-manager" via="ConnectionManager"/>
</component>
That is all.
This functionality already exists in Phoenix, if I understand it
correctly, and can be put into Fortress ( = Phortress? :)) without
breaking backwards compatibility.
This does not solve the "what is a hint" problem, it does not
solve runtime mappings for Cocoon. It only solves the
namespace collision issues. (Note that I *will* take credit for
solving those if someone can extract a working solution from the
above. ;) "Oh, yeah, but that was what I said all along..." )
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Sutic wrote:
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>
>>Does that make sence?
>>If not - what are the pieces that are missing?
>>
>
>You can not pre-build the map as you say. The mappings change
>at runtime.
>
I'm not saying this is a runtime or assemble time issue (assembly can
occur at runtime).
The issue comes down to requesting a component via lookup with
impormation that can be resolved from the type meta.
>Sure, you can recompute the map all the time, but
>why would Cocoon use Avalon then, if they have to do all the
>framework stuff themselves?
>
>Take my word for it Stephen, we need hints.
>
My impresion is that there is a need to be able to declare required
*policy* and you need to declare optional request *context*.
>
>I *hate* to put it this way, but it is true: A lot of thought
>has gone into the concept of using hints, Cocoon uses hints
>*exactly* as they were supposed to be used, and there is no more
>elegant solution. I can give you the requirements for Cocoon, and
>you can say "well, but..." and come up with a solution that does not
>use hints,
>
I'm not saying that you do away with hints - I am saying that the lookup
operation is not the place to pass this information. The container
already has so much infromation available.
>but that solution will be (a) uglier (b) reduce the
>usability of Avalon for Cocoon, meaning that Cocoon will not use A5
>and thus also be (c) utterly worthless in practice, although fine in
>theory.
>
My impression is that your assuming I'm talking about something else.
I'm not discounting the requirements for a client to supply constraints
and/or context to a container. I am disputing the approach of packing
this into the lookup operation.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > how about
>
> Why should I use Avalon if I have to build my own framework
> on top of it before I can get anything done?
c'mon...the ComponentManager interface doesn't "do" anything. You get an
implementation for that. What we call "framework" doesn't do anything.
We have framework implementations for that.
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> how about
Why should I use Avalon if I have to build my own framework
on top of it before I can get anything done?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-06-17 at 14:22, Leo Sutic wrote:
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > Does that make sence?
> > If not - what are the pieces that are missing?
>
> You can not pre-build the map as you say. The mappings change
> at runtime. Sure, you can recompute the map all the time, but
> why would Cocoon use Avalon then, if they have to do all the
> framework stuff themselves?
how about having a service kernel (like Steve proposes), that recomputes
the map, at runtime? Basically, you move the complex mapping into
container space, so component manager (and thus composable) space has
only simple mapping.
something like:
Component
^
| uses <--- define during ComponentManager.lookup(role)
| |
Composable | lookup(composable,
| role);
DynamicDependencyMap <--------
^
|
| configure
|
ContainerKernel
^
| configure
|
DynamicDependencyMapManagementAdaptor
^
|
|
|
whatever modifies sitemap
ComponentManager ==> DefaultComponentManager
ContainerKernel ==> SomeSmartContainer
why is this a bad/impossible idea?
> Take my word for it Stephen, we need hints.
>
> I *hate* to put it this way, but it is true: A lot of thought
> has gone into the concept of using hints, Cocoon uses hints
> *exactly* as they were supposed to be used, and there is no more
> elegant solution. I can give you the requirements for Cocoon, and
> you can say "well, but..." and come up with a solution that does not
> use hints, but that solution will be (a) uglier (b) reduce the
> usability of Avalon for Cocoon, meaning that Cocoon will not use A5
> and thus also be (c) utterly worthless in practice, although fine in
> theory. In short, a waste of our precious time for *both* of us.
> As Stefano said, mapping a 2d set to a 1d set is always
> possible, but in this context it is only of academic value.
even so, could be quite a bit of academic value =)
regards,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>
>>Does that make sence?
>>If not - what are the pieces that are missing?
>
>
> You can not pre-build the map as you say. The mappings change
> at runtime. Sure, you can recompute the map all the time, but
> why would Cocoon use Avalon then, if they have to do all the
> framework stuff themselves?
>
> Take my word for it Stephen, we need hints.
>
> I *hate* to put it this way, but it is true: A lot of thought
> has gone into the concept of using hints, Cocoon uses hints
> *exactly* as they were supposed to be used, and there is no more
> elegant solution. I can give you the requirements for Cocoon, and
> you can say "well, but..." and come up with a solution that does not
> use hints, but that solution will be (a) uglier (b) reduce the
> usability of Avalon for Cocoon, meaning that Cocoon will not use A5
> and thus also be (c) utterly worthless in practice, although fine in
> theory. In short, a waste of our precious time for *both* of us.
> As Stefano said, mapping a 2d set to a 1d set is always
> possible, but in this context it is only of academic value.
We could still be programming in assembler...
the point is that C, Java, and higher level languages define cleaner
semantics, ie meanings.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Does that make sence?
> If not - what are the pieces that are missing?
You can not pre-build the map as you say. The mappings change
at runtime. Sure, you can recompute the map all the time, but
why would Cocoon use Avalon then, if they have to do all the
framework stuff themselves?
Take my word for it Stephen, we need hints.
I *hate* to put it this way, but it is true: A lot of thought
has gone into the concept of using hints, Cocoon uses hints
*exactly* as they were supposed to be used, and there is no more
elegant solution. I can give you the requirements for Cocoon, and
you can say "well, but..." and come up with a solution that does not
use hints, but that solution will be (a) uglier (b) reduce the
usability of Avalon for Cocoon, meaning that Cocoon will not use A5
and thus also be (c) utterly worthless in practice, although fine in
theory. In short, a waste of our precious time for *both* of us.
As Stefano said, mapping a 2d set to a 1d set is always
possible, but in this context it is only of academic value.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>The name "hint" used by ECM is misleading, since Cocoon hints are not
>>something that can be ignored.
>
>
> Cocoon hints *can* be ignored. You will not get the result you may want,
> but processing can continue as long as the correct interface is
> given.
Hmmm, it generally *won't* continue, since the Transformer would
generally throw an exception that the data coming in has a wrong DTD.
> You just get degradation of service. Degradation to the point
> of uselessness, agreed, but that's the fault of a minimalist
> container. Don't use minimalist containers for maximalist apps.
;-)
This is not degradation of service, since the service is not performed.
I could return Saxon instead of Xalan and regard it as degradation of
service, but
> Seriously, Nicola, what is the difference between a CM that ignores
> hints
> and a cocoon config that only has one component instance for each role,
> so that the selector always picks the same?
Implementation-wise, none.
I think that there is a meaning in the whole role-behaviour thing that
is general enough to be exposed by the CM.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> The name "hint" used by ECM is misleading, since Cocoon hints are not
> something that can be ignored.
Cocoon hints *can* be ignored. You will not get the result you may want,
but processing can continue as long as the correct interface is
given. You just get degradation of service. Degradation to the point
of uselessness, agreed, but that's the fault of a minimalist
container. Don't use minimalist containers for maximalist apps.
Seriously, Nicola, what is the difference between a CM that ignores
hints
and a cocoon config that only has one component instance for each role,
so that the selector always picks the same?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 06:30 PM 6/17/2002 +0200, you wrote:
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > So
> >
> > what=role
> > how=constraint
> >
> > Makes perfect sense to me :-)
>
>Stephen,
>
>would not role be just another constraint? That is, we are into the
>"query object" approach.
interface name is just another constraint but interface name != role. Role
= opaque string used to look up dependency.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> So
>
> what=role
> how=constraint
>
> Makes perfect sense to me :-)
Stephen,
would not role be just another constraint? That is, we are into the
"query object" approach.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
>
> Stephen McConnell wrote:
>
>>
>>
>> Nicola Ken Barozzi wrote:
>
> >>
>
>>> I think that a sub-role is general enough to be regarded as not
>>> being container specific.
>>>
>>> Call that subrole, constraint2, or whatever, but what you say is
>>> correct.
>>
>>
>> I would really prefer that we call it a *constraint*. It is
>> something that is supplied by a conponent to a container that the
>> container must fulfil.
>> Sub-role just means something less defined that a role :-)
>
>
> +1 I used sub-role to try and convey the idea that it was more a
> "role" than a simple "hint". Constraint is much better.
>
> So
>
> what=role
> how=constraint
>
> Makes perfect sense to me :-)
>
>>>>> 1) Role: what to do: interface (dependency)
>>>>
>>>>
>>>>
>>>>
>>>> Can be declared in the type meta-info (so interface name can be
>>>> expressed as a opaque key).
>>>
>>>
>>>
>>>
>>> I still think that opaque kwys should be interfaces, or the contract
>>> remains too loose.
>>> But I don't have *that* strong feelings on it.
>>
>>
>> Keep in mind that I'm looking at this from the containers point of
>> view. I am serviceing a consumer object - which means I know the
>> interface alredy and supplying me with the interface name is
>> academic. When you add themeta-info into the picture, the container
>> can be much more responsible about doing what is required - the only
>> change is *where* you declare the interface string (dependecy
>> meta-info declares it as part of the component contract - or - as a
>> part of a lookup argument declares it to a particular type of
>> container what supports that), In fact, I would consider the
>> meta-info approach much more structuraly sound because you can
>> validate things without the expense of instanting the compoent.
>
>
> Hmmm... since I cast the Object I get to (RoleInterface), I personally
> regard using that as a role more clear.
>
> (MyRole) myimpl = sm.lookup(MyRole.class);
>
> is much more clear IMHO than
>
> (MyRole) myimpl = sm.lookup("role-1");
>
> Whatever hiding my container does, ultimately I need that cast, so the
> major decoupling I have by not supplying it goes unused.
>
>>>>> 2) Sub-Role: how to do it: behaviour on environment (dependency)
>>>>
>>>>
>>>> Resolution of the interface via the meta-infomation already
>>>> provides us with access to a dependecy declaration. This dependecy
>>>> declaration can include policy - i.e. specific constraints that
>>>> consumer component requires to be fulfilled by a container when
>>>> making an instance selection. Policy declared inside a dependecy
>>>> declaration implies that the consumer component has knowlege about
>>>> the type of supplier component. This implies a family of components
>>>> and basically the introduction of policy handlers types that are
>>>> recognized by all containers. If the policy is something that is
>>>> unrelated to a consumer component dependency declaration (i.e.
>>>> not-declared in dependecy meta-info), then, and only then, you are
>>>> introducing additional semantics into the process of a component
>>>> lookup. In this scenario, a lookup( String opaque, Constraint
>>>> constraint ) would be required in order for the container to
>>>> differentiate between the identification of candidate supply
>>>> components (using the opaque string), and selection of a single
>>>> component from the candidates using the supplied constraint).
>>>
>>>
>>> Yes, yes, yes! Hey, can we say that the message got across? :-D
>>
>>
>> Let's just say that there is some clarification. :-)
>> But - I have real concerns about extending lookup to support non-type
>> based constraints - in fact (for the moment) my feeling is that this
>> is point where the client component should be requesting a service
>> that specifically suports non-type selection (i.e. its not a
>> container problem).
>
>
> Hmmm...
>
> What do you mean by "suports non-type selection"?
Bad phrase - ! Sorry about that.
What I'm getting at is that if selection of a instance of a service
provider cannot be fulfilled based on available type meta data or
instance level data related to
configuration/contextualization/servicing, then we are talking about
somethign which is outside of the scope of a generic container.
Cheers, Steve.
>
>
>>>>> 3) Hint: suggestion of who should do it: implementation (not
>>>>> mandatory)
>>>>>
>>>>> The name "hint" used by ECM is misleading, since Cocoon hints are
>>>>> not something that can be ignored.
>>>>>
>>>> Which basically means (presumption mode on) that your doing
>>>> sufficient setup in Cocoon to make sure that the ECM hint
>>>> resolution is always sucessfully resolving your supplied policy
>>>> directive (constraint).
>>>
>>>
>>> Yes.
>>>
>>>> Am I getting closer ?
>>>
>>>
>>> I think you've got what I mean :-D
>>>
>> :-D
>
>
> As someone has implied, we are basically putting a special
> ConstraintBasedSelector in Lookup phase.
>
> This gets rid of the Selector but moves the problem upwards...
>
> Personally, I would prefer this rather than having a Selector...
>
> Hmmm...
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>>
>> I think that a sub-role is general enough to be regarded as not being
>> container specific.
>>
>> Call that subrole, constraint2, or whatever, but what you say is correct.
>
> I would really prefer that we call it a *constraint*. It is something
> that is supplied by a conponent to a container that the container must
> fulfil.
> Sub-role just means something less defined that a role :-)
+1 I used sub-role to try and convey the idea that it was more a "role"
than a simple "hint". Constraint is much better.
So
what=role
how=constraint
Makes perfect sense to me :-)
>>>> 1) Role: what to do: interface (dependency)
>>>
>>>
>>>
>>> Can be declared in the type meta-info (so interface name can be
>>> expressed as a opaque key).
>>
>>
>>
>> I still think that opaque kwys should be interfaces, or the contract
>> remains too loose.
>> But I don't have *that* strong feelings on it.
>
> Keep in mind that I'm looking at this from the containers point of view.
> I am serviceing a consumer object - which means I know the interface
> alredy and supplying me with the interface name is academic. When you
> add themeta-info into the picture, the container can be much more
> responsible about doing what is required - the only change is *where*
> you declare the interface string (dependecy meta-info declares it as
> part of the component contract - or - as a part of a lookup argument
> declares it to a particular type of container what supports that), In
> fact, I would consider the meta-info approach much more structuraly
> sound because you can validate things without the expense of instanting
> the compoent.
Hmmm... since I cast the Object I get to (RoleInterface), I personally
regard using that as a role more clear.
(MyRole) myimpl = sm.lookup(MyRole.class);
is much more clear IMHO than
(MyRole) myimpl = sm.lookup("role-1");
Whatever hiding my container does, ultimately I need that cast, so the
major decoupling I have by not supplying it goes unused.
>>>> 2) Sub-Role: how to do it: behaviour on environment (dependency)
>>>
>>> Resolution of the interface via the meta-infomation already provides
>>> us with access to a dependecy declaration. This dependecy
>>> declaration can include policy - i.e. specific constraints that
>>> consumer component requires to be fulfilled by a container when
>>> making an instance selection. Policy declared inside a dependecy
>>> declaration implies that the consumer component has knowlege about
>>> the type of supplier component. This implies a family of components
>>> and basically the introduction of policy handlers types that are
>>> recognized by all containers. If the policy is something that is
>>> unrelated to a consumer component dependency declaration (i.e.
>>> not-declared in dependecy meta-info), then, and only then, you are
>>> introducing additional semantics into the process of a component
>>> lookup. In this scenario, a lookup( String opaque, Constraint
>>> constraint ) would be required in order for the container to
>>> differentiate between the identification of candidate supply
>>> components (using the opaque string), and selection of a single
>>> component from the candidates using the supplied constraint).
>>
>> Yes, yes, yes! Hey, can we say that the message got across? :-D
>
> Let's just say that there is some clarification. :-)
> But - I have real concerns about extending lookup to support non-type
> based constraints - in fact (for the moment) my feeling is that this is
> point where the client component should be requesting a service that
> specifically suports non-type selection (i.e. its not a container problem).
Hmmm...
What do you mean by "suports non-type selection"?
>>>> 3) Hint: suggestion of who should do it: implementation (not mandatory)
>>>>
>>>> The name "hint" used by ECM is misleading, since Cocoon hints are
>>>> not something that can be ignored.
>>>>
>>> Which basically means (presumption mode on) that your doing
>>> sufficient setup in Cocoon to make sure that the ECM hint resolution
>>> is always sucessfully resolving your supplied policy directive
>>> (constraint).
>>
>> Yes.
>>
>>> Am I getting closer ?
>>
>> I think you've got what I mean :-D
>>
> :-D
As someone has implied, we are basically putting a special
ConstraintBasedSelector in Lookup phase.
This gets rid of the Selector but moves the problem upwards...
Personally, I would prefer this rather than having a Selector...
Hmmm...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
>
> Stephen McConnell wrote:
>
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>>
>>>> Nicola Ken Barozzi wrote:
>>>>
>>>>>
>>>>> Stephen McConnell wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Peter Donald wrote:
>>>>>>
>>>>>>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>>>>>>
>>>>>>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>>>>>>
>>>>>>>> Role: what do do
>>>>>>>> Hint: *how* to do it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would not say that. I would say
>>>>>>>
>>>>>>> Role: arbitrary name indicating a dependency
>>>>>>> Hint: metainfo associated with dependency indicating a possible
>>>>>>> policy for selecting from candidate providers.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Tell me how to use flat roles in Cocoon.
>>>>> Tell me.
>>>>>
>>>> Nikolas:
>>>>
>>>> As you know, my knowledge of Cocoon is very limited (its basically
>>>> derived from what you have told me about Cocoon usage of ECM).
>>>> However, I'll try to compose a response :-)
>>>>
>>>> Cocoon creates a sitemap - the sitemap declares info the about the
>>>> "interfaces" and the "preferences" that will result in components
>>>> performing a transitioning of an XML doucment to something else. A
>>>> Cocoon application can look at this sitemap (which can be viewed as
>>>> a set of execution constraints) and validate that the suite of
>>>> components are available to meet thos constraints - where
>>>> availability means (a) I have a component implemetation that is
>>>> capable of providing the service interface, and optionally (b) I
>>>> have a componet implementation that is capable of providing the
>>>> interface relative to the implementation preferences.
>>>
>>>
>>>
>>>
>>> This is *not* optional.
>>> Hints in Cocoon are *not* optional.
>>
>>
>>
>>
>> I have to confess that I am now totally confussed about the term
>> "hint". Based on my english language knowlege - a hint is something
>> that can provide a optional indicator of direction - a hint does not
>> imply anything absolute. However, in the Cocoon context the word
>> "hint"is being used to describe a policy to a container that is
>> required by a client.
>
>
> This is exactly what I think.
>
> It may be wrong, but you got my point.
>
>>> You cannot assume that an XSLT transformer can be replaced by a
>>> ReplaceAllTagsWithCoolTagTransformer do the same thing.
>>> They do *not*, even if they have the *same* interface.
>>>
>>> > So instead of Coocoon hitting something like ECM with a
>>>
>>>> bunch of interface names and tags, Cocoon first of all hits a
>>>> kernel with a configuration of services to build, the kernel
>>>> validates that everything that is needed is available as far as it
>>>> can, registers sitemap directives (role/tag info) against
>>>> identifiable component implementation instances - then at runtime,
>>>> when the role/tag info is supplied the kernal is soiply passing
>>>> back the identifiable component instance from its internal map.
>>>>
>>>> Does that make sence?
>>>> If not - what are the pieces that are missing?
>>>
>>>
>>>
>>>
>>> You are saying the same thing, only saying that hints must be
>>> defined at startup.
>>> "registers sitemap directives (role/tag info)" clearly says that we
>>> *do* have role+hint.
>>>
>>> Defining them at startup or at runtime makes no difference,
>>
>>
>>
>>
>> Agreed.
>>
>>> they are still there, and it makes sense to keep them separate,
>>> since they have different meanings:
>>
>>
>>
>>
>> I agree that these are better keep seperate. However - I'm now
>> feeling very certain that there is a general mixup of terms (at least
>> I know I'm cofussed on the subject of roles and hints).
>
>
> ;-) yeah
>
>> Imaging we have:
>>
>> client-context - information supplied by a client that *may* be
>> used by a container to influence its response - client context
>> *may* be ignored by a container
>>
>> client-policy - information supplied by a client that directly
>> impacts container behavior and represents part of the
>> client/container
>> contract - client policy *must* be understood by the container
>> if the container is going to service the client request
>>
>> Let's ignore client-context for a moment.
>>
>> The primary concern is where policy information is derived. A
>> component implementation could declare policy support at a type level
>> or at an instance level. Type level policy can be declared in
>> meta-info and can be managed by a container. Instance level policy
>> (e.g. taking a component type, instantiating it, and differentiating
>> the instance through conguration/context/service state has the
>> potential to establish the instance as a component capable of
>> supporting a particular policy. This type of instance level policy
>> can be used by a container to differentiate when selecting a
>> component to return to a client. Both type and instance policy can
>> be declared in the context of a particular application - type level
>> is generic and would be usable across containers - instance level is
>> getting container specific because you have to introduce some
>> knowlege into the container about the establishment of identifiable
>> instances.
>
>
> Good explanation, yes.
>
> I think that a sub-role is general enough to be regarded as not being
> container specific.
>
> Call that subrole, constraint2, or whatever, but what you say is correct.
I would really prefer that we call it a *constraint*.
It is something that is supplied by a conponent to a container that the
container must fulfil.
Sub-role just means something less defined that a role :-)
>
>
>>>
>>> 1) Role: what to do: interface (dependency)
>>
>>
>> Can be declared in the type meta-info (so interface name can be
>> expressed as a opaque key).
>
>
> I still think that opaque kwys should be interfaces, or the contract
> remains too loose.
> But I don't have *that* strong feelings on it.
Keep in mind that I'm looking at this from the containers point of view.
I am serviceing a consumer object - which means I know the interface
alredy and supplying me with the interface name is academic. When you
add themeta-info into the picture, the container can be much more
responsible about doing what is required - the only change is *where*
you declare the interface string (dependecy meta-info declares it as
part of the component contract - or - as a part of a lookup argument
declares it to a particular type of container what supports that), In
fact, I would consider the meta-info approach much more structuraly
sound because you can validate things without the expense of instanting
the compoent.
>
>
>>> 2) Sub-Role: how to do it: behaviour on environment (dependency)
>>
>>
>>
>> Resolution of the interface via the meta-infomation already provides
>> us with access to a dependecy declaration. This dependecy
>> declaration can include policy - i.e. specific constraints that
>> consumer component requires to be fulfilled by a container when
>> making an instance selection. Policy declared inside a dependecy
>> declaration implies that the consumer component has knowlege about
>> the type of supplier component. This implies a family of components
>> and basically the introduction of policy handlers types that are
>> recognized by all containers. If the policy is something that is
>> unrelated to a consumer component dependency declaration (i.e.
>> not-declared in dependecy meta-info), then, and only then, you are
>> introducing additional semantics into the process of a component
>> lookup. In this scenario, a lookup( String opaque, Constraint
>> constraint ) would be required in order for the container to
>> differentiate between the identification of candidate supply
>> components (using the opaque string), and selection of a single
>> component from the candidates using the supplied constraint).
>
>
> Yes, yes, yes! Hey, can we say that the message got across? :-D
Let's just say that there is some clarification. :-)
But - I have real concerns about extending lookup to support non-type
based constraints - in fact (for the moment) my feeling is that this is
point where the client component should be requesting a service that
specifically suports non-type selection (i.e. its not a container problem).
>
>
>>> 3) Hint: suggestion of who should do it: implementation (not mandatory)
>>>
>>> The name "hint" used by ECM is misleading, since Cocoon hints are
>>> not something that can be ignored.
>>>
>> Which basically means (presumption mode on) that your doing
>> sufficient setup in Cocoon to make sure that the ECM hint resolution
>> is always sucessfully resolving your supplied policy directive
>> (constraint).
>
>
> Yes.
>
>> Am I getting closer ?
>
>
> I think you've got what I mean :-D
>
:-D
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>>
>>>> Stephen McConnell wrote:
>>>>
>>>>>
>>>>>
>>>>> Peter Donald wrote:
>>>>>
>>>>>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>>>>>
>>>>>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>>>>>
>>>>>>> Role: what do do
>>>>>>> Hint: *how* to do it
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would not say that. I would say
>>>>>>
>>>>>> Role: arbitrary name indicating a dependency
>>>>>> Hint: metainfo associated with dependency indicating a possible
>>>>>> policy for selecting from candidate providers.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++1
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Tell me how to use flat roles in Cocoon.
>>>> Tell me.
>>>>
>>> Nikolas:
>>>
>>> As you know, my knowledge of Cocoon is very limited (its basically
>>> derived from what you have told me about Cocoon usage of ECM).
>>> However, I'll try to compose a response :-)
>>>
>>> Cocoon creates a sitemap - the sitemap declares info the about the
>>> "interfaces" and the "preferences" that will result in components
>>> performing a transitioning of an XML doucment to something else. A
>>> Cocoon application can look at this sitemap (which can be viewed as a
>>> set of execution constraints) and validate that the suite of
>>> components are available to meet thos constraints - where
>>> availability means (a) I have a component implemetation that is
>>> capable of providing the service interface, and optionally (b) I have
>>> a componet implementation that is capable of providing the interface
>>> relative to the implementation preferences.
>>
>>
>>
>> This is *not* optional.
>> Hints in Cocoon are *not* optional.
>
>
>
> I have to confess that I am now totally confussed about the term "hint".
> Based on my english language knowlege - a hint is something that can
> provide a optional indicator of direction - a hint does not imply
> anything absolute. However, in the Cocoon context the word "hint"is
> being used to describe a policy to a container that is required by a
> client.
This is exactly what I think.
It may be wrong, but you got my point.
>> You cannot assume that an XSLT transformer can be replaced by a
>> ReplaceAllTagsWithCoolTagTransformer do the same thing.
>> They do *not*, even if they have the *same* interface.
>>
>> > So instead of Coocoon hitting something like ECM with a
>>
>>> bunch of interface names and tags, Cocoon first of all hits a kernel
>>> with a configuration of services to build, the kernel validates that
>>> everything that is needed is available as far as it can, registers
>>> sitemap directives (role/tag info) against identifiable component
>>> implementation instances - then at runtime, when the role/tag info is
>>> supplied the kernal is soiply passing back the identifiable component
>>> instance from its internal map.
>>>
>>> Does that make sence?
>>> If not - what are the pieces that are missing?
>>
>>
>>
>> You are saying the same thing, only saying that hints must be defined
>> at startup.
>> "registers sitemap directives (role/tag info)" clearly says that we
>> *do* have role+hint.
>>
>> Defining them at startup or at runtime makes no difference,
>
>
>
> Agreed.
>
>> they are still there, and it makes sense to keep them separate, since
>> they have different meanings:
>
>
>
> I agree that these are better keep seperate. However - I'm now feeling
> very certain that there is a general mixup of terms (at least I know I'm
> cofussed on the subject of roles and hints).
;-) yeah
> Imaging we have:
>
> client-context - information supplied by a client that *may* be
> used by a container to influence its response - client context
> *may* be ignored by a container
>
> client-policy - information supplied by a client that directly
> impacts container behavior and represents part of the client/container
> contract - client policy *must* be understood by the container
> if the container is going to service the client request
>
> Let's ignore client-context for a moment.
>
> The primary concern is where policy information is derived. A component
> implementation could declare policy support at a type level or at an
> instance level. Type level policy can be declared in meta-info and can
> be managed by a container. Instance level policy (e.g. taking a
> component type, instantiating it, and differentiating the instance
> through conguration/context/service state has the potential to establish
> the instance as a component capable of supporting a particular policy.
> This type of instance level policy can be used by a container to
> differentiate when selecting a component to return to a client. Both
> type and instance policy can be declared in the context of a particular
> application - type level is generic and would be usable across
> containers - instance level is getting container specific because you
> have to introduce some knowlege into the container about the
> establishment of identifiable instances.
Good explanation, yes.
I think that a sub-role is general enough to be regarded as not being
container specific.
Call that subrole, constraint2, or whatever, but what you say is correct.
>>
>> 1) Role: what to do: interface (dependency)
>
> Can be declared in the type meta-info (so interface name can be
> expressed as a opaque key).
I still think that opaque kwys should be interfaces, or the contract
remains too loose.
But I don't have *that* strong feelings on it.
>> 2) Sub-Role: how to do it: behaviour on environment (dependency)
>
>
> Resolution of the interface via the meta-infomation already provides us
> with access to a dependecy declaration. This dependecy declaration can
> include policy - i.e. specific constraints that consumer component
> requires to be fulfilled by a container when making an instance
> selection. Policy declared inside a dependecy declaration implies that
> the consumer component has knowlege about the type of supplier
> component. This implies a family of components and basically the
> introduction of policy handlers types that are recognized by all
> containers.
> If the policy is something that is unrelated to a consumer component
> dependency declaration (i.e. not-declared in dependecy meta-info), then,
> and only then, you are introducing additional semantics into the process
> of a component lookup. In this scenario, a lookup( String opaque,
> Constraint constraint ) would be required in order for the container to
> differentiate between the identification of candidate supply components
> (using the opaque string), and selection of a single component from the
> candidates using the supplied constraint).
Yes, yes, yes! Hey, can we say that the message got across? :-D
>> 3) Hint: suggestion of who should do it: implementation (not mandatory)
>>
>> The name "hint" used by ECM is misleading, since Cocoon hints are not
>> something that can be ignored.
>>
> Which basically means (presumption mode on) that your doing sufficient
> setup in Cocoon to make sure that the ECM hint resolution is always
> sucessfully resolving your supplied policy directive (constraint).
Yes.
> Am I getting closer ?
I think you've got what I mean :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>>
>>>> Peter Donald wrote:
>>>>
>>>>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>>>>
>>>>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>>>>
>>>>>> Role: what do do
>>>>>> Hint: *how* to do it
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I would not say that. I would say
>>>>>
>>>>> Role: arbitrary name indicating a dependency
>>>>> Hint: metainfo associated with dependency indicating a possible
>>>>> policy for selecting from candidate providers.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ++++++++++++++++++++++++++++++++++++++++++++1
>>>
>>>
>>>
>>>
>>> Tell me how to use flat roles in Cocoon.
>>> Tell me.
>>>
>> Nikolas:
>>
>> As you know, my knowledge of Cocoon is very limited (its basically
>> derived from what you have told me about Cocoon usage of ECM).
>> However, I'll try to compose a response :-)
>>
>> Cocoon creates a sitemap - the sitemap declares info the about the
>> "interfaces" and the "preferences" that will result in components
>> performing a transitioning of an XML doucment to something else. A
>> Cocoon application can look at this sitemap (which can be viewed as a
>> set of execution constraints) and validate that the suite of
>> components are available to meet thos constraints - where
>> availability means (a) I have a component implemetation that is
>> capable of providing the service interface, and optionally (b) I have
>> a componet implementation that is capable of providing the interface
>> relative to the implementation preferences.
>
>
> This is *not* optional.
> Hints in Cocoon are *not* optional.
I have to confess that I am now totally confussed about the term "hint".
Based on my english language knowlege - a hint is something that can
provide a optional indicator of direction - a hint does not imply
anything absolute. However, in the Cocoon context the word "hint"is
being used to describe a policy to a container that is required by a
client.
>
> You cannot assume that an XSLT transformer can be replaced by a
> ReplaceAllTagsWithCoolTagTransformer do the same thing.
> They do *not*, even if they have the *same* interface.
>
> > So instead of Coocoon hitting something like ECM with a
>
>> bunch of interface names and tags, Cocoon first of all hits a kernel
>> with a configuration of services to build, the kernel validates that
>> everything that is needed is available as far as it can, registers
>> sitemap directives (role/tag info) against identifiable component
>> implementation instances - then at runtime, when the role/tag info is
>> supplied the kernal is soiply passing back the identifiable component
>> instance from its internal map.
>>
>> Does that make sence?
>> If not - what are the pieces that are missing?
>
>
> You are saying the same thing, only saying that hints must be defined
> at startup.
> "registers sitemap directives (role/tag info)" clearly says that we
> *do* have role+hint.
>
> Defining them at startup or at runtime makes no difference,
Agreed.
> they are still there, and it makes sense to keep them separate, since
> they have different meanings:
I agree that these are better keep seperate. However - I'm now feeling
very certain that there is a general mixup of terms (at least I know I'm
cofussed on the subject of roles and hints).
Imaging we have:
client-context - information supplied by a client that *may* be
used by a container to influence its response - client context
*may* be ignored by a container
client-policy - information supplied by a client that directly
impacts container behavior and represents part of the client/container
contract - client policy *must* be understood by the container
if the container is going to service the client request
Let's ignore client-context for a moment.
The primary concern is where policy information is derived. A component
implementation could declare policy support at a type level or at an
instance level. Type level policy can be declared in meta-info and can
be managed by a container. Instance level policy (e.g. taking a
component type, instantiating it, and differentiating the instance
through conguration/context/service state has the potential to establish
the instance as a component capable of supporting a particular policy.
This type of instance level policy can be used by a container to
differentiate when selecting a component to return to a client. Both
type and instance policy can be declared in the context of a particular
application - type level is generic and would be usable across
containers - instance level is getting container specific because you
have to introduce some knowlege into the container about the
establishment of identifiable instances.
>
>
> 1) Role: what to do: interface (dependency)
Can be declared in the type meta-info (so interface name can be
expressed as a opaque key).
>
> 2) Sub-Role: how to do it: behaviour on environment (dependency)
Resolution of the interface via the meta-infomation already provides us
with access to a dependecy declaration. This dependecy declaration can
include policy - i.e. specific constraints that consumer component
requires to be fulfilled by a container when making an instance
selection. Policy declared inside a dependecy declaration implies that
the consumer component has knowlege about the type of supplier
component. This implies a family of components and basically the
introduction of policy handlers types that are recognized by all
containers.
If the policy is something that is unrelated to a consumer component
dependency declaration (i.e. not-declared in dependecy meta-info), then,
and only then, you are introducing additional semantics into the process
of a component lookup. In this scenario, a lookup( String opaque,
Constraint constraint ) would be required in order for the container to
differentiate between the identification of candidate supply components
(using the opaque string), and selection of a single component from the
candidates using the supplied constraint).
>
> 3) Hint: suggestion of who should do it: implementation (not mandatory)
>
> The name "hint" used by ECM is misleading, since Cocoon hints are not
> something that can be ignored.
>
Which basically means (presumption mode on) that your doing sufficient
setup in Cocoon to make sure that the ECM hint resolution is always
sucessfully resolving your supplied policy directive (constraint).
Am I getting closer ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Peter Donald wrote:
>>>
>>>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>>>
>>>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>>>
>>>>> Role: what do do
>>>>> Hint: *how* to do it
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I would not say that. I would say
>>>>
>>>> Role: arbitrary name indicating a dependency
>>>> Hint: metainfo associated with dependency indicating a possible
>>>> policy for selecting from candidate providers.
>>>
>>>
>>>
>>>
>>>
>>> ++++++++++++++++++++++++++++++++++++++++++++1
>>
>>
>>
>> Tell me how to use flat roles in Cocoon.
>> Tell me.
>>
> Nikolas:
>
> As you know, my knowledge of Cocoon is very limited (its basically
> derived from what you have told me about Cocoon usage of ECM). However,
> I'll try to compose a response :-)
>
> Cocoon creates a sitemap - the sitemap declares info the about the
> "interfaces" and the "preferences" that will result in components
> performing a transitioning of an XML doucment to something else. A
> Cocoon application can look at this sitemap (which can be viewed as a
> set of execution constraints) and validate that the suite of components
> are available to meet thos constraints - where availability means (a) I
> have a component implemetation that is capable of providing the service
> interface, and optionally (b) I have a componet implementation that is
> capable of providing the interface relative to the implementation
> preferences.
This is *not* optional.
Hints in Cocoon are *not* optional.
You cannot assume that an XSLT transformer can be replaced by a
ReplaceAllTagsWithCoolTagTransformer do the same thing.
They do *not*, even if they have the *same* interface.
> So instead of Coocoon hitting something like ECM with a
> bunch of interface names and tags, Cocoon first of all hits a kernel
> with a configuration of services to build, the kernel validates that
> everything that is needed is available as far as it can, registers
> sitemap directives (role/tag info) against identifiable component
> implementation instances - then at runtime, when the role/tag info is
> supplied the kernal is soiply passing back the identifiable component
> instance from its internal map.
>
> Does that make sence?
> If not - what are the pieces that are missing?
You are saying the same thing, only saying that hints must be defined at
startup.
"registers sitemap directives (role/tag info)" clearly says that we *do*
have role+hint.
Defining them at startup or at runtime makes no difference, they are
still there, and it makes sense to keep them separate, since they have
different meanings:
1) Role: what to do: interface (dependency)
2) Sub-Role: how to do it: behaviour on environment (dependency)
3) Hint: suggestion of who should do it: implementation (not mandatory)
The name "hint" used by ECM is misleading, since Cocoon hints are not
something that can be ignored.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> Peter Donald wrote:
>>
>>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>>
>>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>>
>>>> Role: what do do
>>>> Hint: *how* to do it
>>>
>>>
>>>
>>>
>>> I would not say that. I would say
>>>
>>> Role: arbitrary name indicating a dependency
>>> Hint: metainfo associated with dependency indicating a possible
>>> policy for selecting from candidate providers.
>>
>>
>>
>>
>> ++++++++++++++++++++++++++++++++++++++++++++1
>
>
> Tell me how to use flat roles in Cocoon.
> Tell me.
>
Nikolas:
As you know, my knowledge of Cocoon is very limited (its basically
derived from what you have told me about Cocoon usage of ECM). However,
I'll try to compose a response :-)
Cocoon creates a sitemap - the sitemap declares info the about the
"interfaces" and the "preferences" that will result in components
performing a transitioning of an XML doucment to something else. A
Cocoon application can look at this sitemap (which can be viewed as a
set of execution constraints) and validate that the suite of components
are available to meet thos constraints - where availability means (a) I
have a component implemetation that is capable of providing the service
interface, and optionally (b) I have a componet implementation that is
capable of providing the interface relative to the implementation
preferences. So instead of Coocoon hitting something like ECM with a
bunch of interface names and tags, Cocoon first of all hits a kernel
with a configuration of services to build, the kernel validates that
everything that is needed is available as far as it can, registers
sitemap directives (role/tag info) against identifiable component
implementation instances - then at runtime, when the role/tag info is
supplied the kernal is soiply passing back the identifiable component
instance from its internal map.
Does that make sence?
If not - what are the pieces that are missing?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> At 11:16 AM 6/17/2002 +0200, you wrote:
>>
>>> role+hint is *not* a simple way of declaring role="base+hint"
>>>
>>> Role: what do do
>>> Hint: *how* to do it
>>
>>
>>
>> I would not say that. I would say
>>
>> Role: arbitrary name indicating a dependency
>> Hint: metainfo associated with dependency indicating a possible policy
>> for selecting from candidate providers.
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++1
Tell me how to use flat roles in Cocoon.
Tell me.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 11:16 AM 6/17/2002 +0200, you wrote:
>
>> role+hint is *not* a simple way of declaring role="base+hint"
>>
>> Role: what do do
>> Hint: *how* to do it
>
>
> I would not say that. I would say
>
> Role: arbitrary name indicating a dependency
> Hint: metainfo associated with dependency indicating a possible policy
> for selecting from candidate providers.
++++++++++++++++++++++++++++++++++++++++++++1
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 11:16 AM 6/17/2002 +0200, you wrote:
>role+hint is *not* a simple way of declaring role="base+hint"
>
>Role: what do do
>Hint: *how* to do it
I would not say that. I would say
Role: arbitrary name indicating a dependency
Hint: metainfo associated with dependency indicating a possible policy for
selecting from candidate providers.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>On Mon, 2002-06-17 at 11:16, Nicola Ken Barozzi wrote:
>
>
>>Leo Simons wrote:
>>
>>
>>>>>IOW:
>>>>>making the 2-d to 1-d mapping part of the caller instead of the callee
>>>>>simplifies the use of the callee where there is only 1-d.
>>>>>
>>>>>
>>>>C'mon, what do we have java method overloading for? Berin proposed to
>>>>have both
>>>>
>>>>lookup(role)
>>>>
>>>>and
>>>>
>>>>lookup(role,hint);
>>>>
>>>>if you don't have any hint to pass, don't.
>>>>
>>>>
>>>the thing with the CM interface is that every container that wants to be
>>>useful will have to provide a good implementation. The implementation is
>>>simpler (faster?) if you don't have to provide a lookup(role,hint)
>>>function. My natural reaction was to declare the method optional (with
>>>an UnsupportedOperationException option), but it was correctly pointed
>>>out that this is not very good as you won't know that the framework is
>>>exactly the same everywhere.
>>>
>>>This is not an issue if the hint is truly an optional part of the lookup
>>>
>>>// impl:
>>>Object lookup(String role, Object hint)
>>>{ return lookup(role) };
>>>
>>>
>>Ok, let's make this clear:
>>
>>role+hint is *not* a simple way of declaring role="base+hint"
>>
>>Role: what do do
>>Hint: *how* to do it
>>
>>Specifying a role, I just need something to be done, giving a hint I
>>also narrow the focus on a specific "way" of doing it.
>>
>>
>
>I wasn't indicating otherwise; in fact, I wasn't indicating something
>like that at all. If we clearly define a "hint" as a hint, ie safe to
>ignore, that's cool. If we don't, there's less chance for compromise.
>
>
>
>>Please reread my mails on this subject, and comment on those, especially
>>the last one with the SSLConection example.
>>
>>
>
>you talk of "subroles". Subroles should be defined as a "part of" the
>role.
>
>ie:
>
>Role: what to do
>Hint: suggest how to do it
>
>Subrole: just part of what to do, so part of role. Semantics up to
>application.
>
>
>
>>Hints are not part of the role IMO, they have different semantics.
>>
>>This is why the methid needs to be there, although containers can decide
>> to ignore the hint (they could also ignore the role btw, but makes
>>them ever less useful).
>>
>>
>
>but they wouldn't pass "100% pure avalon" testing, whereas they would if
>they ignore the hint.
>
>options:
>1 - don't allow for hints
>
my preference.
>2 - allow for hints, but also allow for them to be ignored
>
which starts to mix in management semantics which complicates life - are
you deriving from meta or are you deriving from a string and forcing a
limitations on a component to use a particular container type.
>3 - require support for an object part in the CM lookup (where "hint is
>an improper term as it is not optional)
>
very opposed to this
>4 - create a Role class/object that also has support for hints
>
still opposed
>
>I'm okay with 1 & 2.
>
I'm ok with 1.
Option 2 will bite us hard.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-06-17 at 11:16, Nicola Ken Barozzi wrote:
>
> Leo Simons wrote:
> >>>IOW:
> >>>making the 2-d to 1-d mapping part of the caller instead of the callee
> >>>simplifies the use of the callee where there is only 1-d.
> >>
> >>C'mon, what do we have java method overloading for? Berin proposed to
> >>have both
> >>
> >> lookup(role)
> >>
> >>and
> >>
> >> lookup(role,hint);
> >>
> >>if you don't have any hint to pass, don't.
> >
> >
> > the thing with the CM interface is that every container that wants to be
> > useful will have to provide a good implementation. The implementation is
> > simpler (faster?) if you don't have to provide a lookup(role,hint)
> > function. My natural reaction was to declare the method optional (with
> > an UnsupportedOperationException option), but it was correctly pointed
> > out that this is not very good as you won't know that the framework is
> > exactly the same everywhere.
> >
> > This is not an issue if the hint is truly an optional part of the lookup
> >
> > // impl:
> > Object lookup(String role, Object hint)
> > { return lookup(role) };
>
>
> Ok, let's make this clear:
>
> role+hint is *not* a simple way of declaring role="base+hint"
>
> Role: what do do
> Hint: *how* to do it
>
> Specifying a role, I just need something to be done, giving a hint I
> also narrow the focus on a specific "way" of doing it.
I wasn't indicating otherwise; in fact, I wasn't indicating something
like that at all. If we clearly define a "hint" as a hint, ie safe to
ignore, that's cool. If we don't, there's less chance for compromise.
> Please reread my mails on this subject, and comment on those, especially
> the last one with the SSLConection example.
you talk of "subroles". Subroles should be defined as a "part of" the
role.
ie:
Role: what to do
Hint: suggest how to do it
Subrole: just part of what to do, so part of role. Semantics up to
application.
> Hints are not part of the role IMO, they have different semantics.
>
> This is why the methid needs to be there, although containers can decide
> to ignore the hint (they could also ignore the role btw, but makes
> them ever less useful).
but they wouldn't pass "100% pure avalon" testing, whereas they would if
they ignore the hint.
options:
1 - don't allow for hints
2 - allow for hints, but also allow for them to be ignored
3 - require support for an object part in the CM lookup (where "hint is
an improper term as it is not optional)
4 - create a Role class/object that also has support for hints
I'm okay with 1 & 2.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>>IOW:
>>>making the 2-d to 1-d mapping part of the caller instead of the callee
>>>simplifies the use of the callee where there is only 1-d.
>>
>>C'mon, what do we have java method overloading for? Berin proposed to
>>have both
>>
>> lookup(role)
>>
>>and
>>
>> lookup(role,hint);
>>
>>if you don't have any hint to pass, don't.
>
>
> the thing with the CM interface is that every container that wants to be
> useful will have to provide a good implementation. The implementation is
> simpler (faster?) if you don't have to provide a lookup(role,hint)
> function. My natural reaction was to declare the method optional (with
> an UnsupportedOperationException option), but it was correctly pointed
> out that this is not very good as you won't know that the framework is
> exactly the same everywhere.
>
> This is not an issue if the hint is truly an optional part of the lookup
>
> // impl:
> Object lookup(String role, Object hint)
> { return lookup(role) };
Ok, let's make this clear:
role+hint is *not* a simple way of declaring role="base+hint"
Role: what do do
Hint: *how* to do it
Specifying a role, I just need something to be done, giving a hint I
also narrow the focus on a specific "way" of doing it.
Please reread my mails on this subject, and comment on those, especially
the last one with the SSLConection example.
Hints are not part of the role IMO, they have different semantics.
This is why the methid needs to be there, although containers can decide
to ignore the hint (they could also ignore the role btw, but makes
them ever less useful).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > IOW:
> > making the 2-d to 1-d mapping part of the caller instead of the callee
> > simplifies the use of the callee where there is only 1-d.
>
> C'mon, what do we have java method overloading for? Berin proposed to
> have both
>
> lookup(role)
>
> and
>
> lookup(role,hint);
>
> if you don't have any hint to pass, don't.
the thing with the CM interface is that every container that wants to be
useful will have to provide a good implementation. The implementation is
simpler (faster?) if you don't have to provide a lookup(role,hint)
function. My natural reaction was to declare the method optional (with
an UnsupportedOperationException option), but it was correctly pointed
out that this is not very good as you won't know that the framework is
exactly the same everywhere.
This is not an issue if the hint is truly an optional part of the lookup
// impl:
Object lookup(String role, Object hint)
{ return lookup(role) };
but it has been suggested that it is, in fact, not.
(...)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> > This looks like a hack imposed by a framework constraint that shouldn't
> > be there.
>
> and that last sentence isn't really true. Because doing those two things
> at once eases the use of the lookup() method if there is no need for an
> "y", and in a completely well-designed system there should very rarely
> be a need for "y", this decision was made. It is not a hack.
Probably, coming from a system where 'rarely used' is a big understated,
I'm biased.
> IOW:
> making the 2-d to 1-d mapping part of the caller instead of the callee
> simplifies the use of the callee where there is only 1-d.
C'mon, what do we have java method overloading for? Berin proposed to
have both
lookup(role)
and
lookup(role,hint);
if you don't have any hint to pass, don't.
> on a more pragmatic front, it is a pattern used in all other lookup
> mechanisms.
Only when the number of dimensions of the lookup is not known a-priori.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-06-14 at 17:30, Stefano Mazzocchi wrote:
> Peter Royal wrote:
>
> > nor have I seen an example that *requires* a hint, they can all be refactored
> > into a single lookup key.
>
> Of course, this is trivial topology: any two dimensional infinite
> discrete sets can be mapped onto a one dimensional infinite discrete
> set.
>
> The problem is not feasibility, is semantics.
yup.
> when you do something like
>
> lookup(x,y);
>
> you are explicitly keeping the two dimensions separate, when you do
>
> lookup(x+y);
>
> you are actually doing two conceptual things at once
>
> 1) (x,y) -> x+y [2-d mapping into 1-d mapping]
> 2) x+y -> component [1-d mapping into 1-d mapping]
>
> This looks like a hack imposed by a framework constraint that shouldn't
> be there.
and that last sentence isn't really true. Because doing those two things
at once eases the use of the lookup() method if there is no need for an
"y", and in a completely well-designed system there should very rarely
be a need for "y", this decision was made. It is not a hack.
IOW:
making the 2-d to 1-d mapping part of the caller instead of the callee
simplifies the use of the callee where there is only 1-d.
on a more pragmatic front, it is a pattern used in all other lookup
mechanisms.
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Royal wrote:
> nor have I seen an example that *requires* a hint, they can all be refactored
> into a single lookup key.
Of course, this is trivial topology: any two dimensional infinite
discrete sets can be mapped onto a one dimensional infinite discrete
set.
The problem is not feasibility, is semantics.
when you do something like
lookup(x,y);
you are explicitly keeping the two dimensions separate, when you do
lookup(x+y);
you are actually doing two conceptual things at once
1) (x,y) -> x+y [2-d mapping into 1-d mapping]
2) x+y -> component [1-d mapping into 1-d mapping]
This looks like a hack imposed by a framework constraint that shouldn't
be there.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 12 June 2002 08:52 am, Berin Loritsch wrote:
> > But I do agree with you, there is no specific need for a
> > ComponentSelector,
> > nor have I seen an example that *requires* a hint, they can
> > all be refactored
> > into a single lookup key.
>
> It just makes it easier to distinguish between ROLE/extension
> if they are passed in separately. You don't have to do any
> string manipulation either to create the lookup key or to validate
> the role name.
And thus.. why introduce that notion at the core of framework when it is
really just an ease-of-use idiom for Cocoon :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Royal [mailto:proyal@apache.org]
>
> On Tuesday 11 June 2002 08:33 pm, Peter Donald wrote:
> > Even if you no go the path of the GeneratorManager, Would it not be
> > wiser to generate an object per-path through pipeline.
> Something along
> > the lines of
> >
> > class PipelinePath53
> > {
> > private static final String GEN_FILE = Generator.ROLE + "/file";
> > private static final String TRAN_XSLT = Transformer.ROLE
> + "/xslt";
>
> Except that the sitemap (where the pipelines are defined) is
> no longer
> converted to java code, its interpreted.
Right.
> But I do agree with you, there is no specific need for a
> ComponentSelector,
> nor have I seen an example that *requires* a hint, they can
> all be refactored
> into a single lookup key.
> -pete
It just makes it easier to distinguish between ROLE/extension
if they are passed in separately. You don't have to do any
string manipulation either to create the lookup key or to validate
the role name.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 11 June 2002 08:33 pm, Peter Donald wrote:
> Even if you no go the path of the GeneratorManager, Would it not be wiser
> to generate an object per-path through pipeline. Something along the lines
> of
>
> class PipelinePath53
> {
> private static final String GEN_FILE = Generator.ROLE + "/file";
> private static final String TRAN_XSLT = Transformer.ROLE + "/xslt";
Except that the sitemap (where the pipelines are defined) is no longer
converted to java code, its interpreted.
The composite value could still be stored as a variable though. You might be
able to dynamically select the component to use at runtime though, I'm not
sure if the variable substitution is possible on the component type..
But I do agree with you, there is no specific need for a ComponentSelector,
nor have I seen an example that *requires* a hint, they can all be refactored
into a single lookup key.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Wed, 12 Jun 2002 10:24, Peter Royal wrote:
> On Tuesday 11 June 2002 07:35 pm, Peter Donald wrote:
> > > Another key difference is that the Cocoon model has a requirement
> > > to re-connect the hint mappings at runtime--whereas the Merlin
> > > model does it all at init time.
> >
> > Can you explain that? You aquire components based on request parameters
> > but the request parameters supply constraints and not hints (ie "ssl" vs
> > "xalan").
>
> Cocoon's pipelines are assembled dynamically at runtime. The main pipeline
> component types are Generators, Transformers and Serializers.
>
> Each one is implemented as a ComponentSelector with the hint specifying
> which component to use.
>
> For an example:
>
> <map:generate type="file"/>
> <map:transform type="xslt"/>
> <map:transform type="custom"/>
> <map:serialize type="xml"/>
>
> The java code is akin to
>
> ComponentSelector generatorSelector = cm.lookup( Generator.ROLE );
> Generator g = generatorSelector.select( "file" );
Even if you no go the path of the GeneratorManager, Would it not be wiser to
generate an object per-path through pipeline. Something along the lines of
class PipelinePath53
{
private static final String GEN_FILE = Generator.ROLE + "/file";
private static final String TRAN_XSLT = Transformer.ROLE + "/xslt";
...
void compose(ComponentManager cm)
{
Generator g = cm.lookup( GEN_FILE);
Transformer t = cm.lookup( TRAN_XSLT );
}
...
}
>
> ... etc etc.
>
> I don't see why there can't be a specific GeneratorManager that is returned
> to let you specify specific generators. The GeneratorManager,
> TransformerManager and SerializerManager would all be nearly identical
> though, thus the thinking of abstracting out ComponentSelector-style.
> -pete
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 11 June 2002 07:35 pm, Peter Donald wrote:
> > Another key difference is that the Cocoon model has a requirement
> > to re-connect the hint mappings at runtime--whereas the Merlin
> > model does it all at init time.
>
> Can you explain that? You aquire components based on request parameters but
> the request parameters supply constraints and not hints (ie "ssl" vs
> "xalan").
Cocoon's pipelines are assembled dynamically at runtime. The main pipeline
component types are Generators, Transformers and Serializers.
Each one is implemented as a ComponentSelector with the hint specifying which
component to use.
For an example:
<map:generate type="file"/>
<map:transform type="xslt"/>
<map:transform type="custom"/>
<map:serialize type="xml"/>
The java code is akin to
ComponentSelector generatorSelector = cm.lookup( Generator.ROLE );
Generator g = generatorSelector.select( "file" );
... etc etc.
I don't see why there can't be a specific GeneratorManager that is returned
to let you specify specific generators. The GeneratorManager,
TransformerManager and SerializerManager would all be nearly identical
though, thus the thinking of abstracting out ComponentSelector-style.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Tue, 11 Jun 2002 22:52, Berin Loritsch wrote:
> > Another key difference is that the Cocoon model has a
> requirement to
> > re-connect the hint mappings at runtime--whereas the Merlin
> model does
> > it all at init time.
>
> Can you explain that? You aquire components based on request
> parameters but
> the request parameters supply constraints and not hints (ie "ssl" vs
> "xalan").
The Cocoon Sitemap is either compiled (the old fashioned way) or
interpreted. The sitemap file can change at any time. The definition
of a pipeline is quite dynamic. In fact, the selection criteria for
which Generator/Transformer/Serializer can depend on anything from
the time of day to the price of tea in China. There are request
parameters, session parameters, request methods, URI, etc.
The fact that the mapping can be reloaded and reused at runtime makes
it a bit more difficult to do init-time mapping.
I'm not very familiar with Merlin, but I am familiar with Cocoon.
You see, it is not so much as which transformer satisfies the
need for a transformer, but that the transformer does the requested
work.
IOW
I have a transformer that takes certain elements from the XML, uses
them to gather information from a database, and then replace those
original elements with ones generated from the data I pulled from the
database.
Now, I could care less if it is done with an XSLT transformer using
ScriptBeans or if it is a custom hardcoded transformer. All I care
about is that the output of the transformer does what I asked it to.
With Cocoon, this is set up each time the sitemap is read.
Unfortunately,
there is no way to guarantee that the sitemap won't change unless we
hardcode the sitemap. In practice, that is more work than it's worth.
So, I am open to input on how you would solve this problem...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Tue, 11 Jun 2002 22:52, Berin Loritsch wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > This is very very similar to what Stephen is doing in Merlin wrt to
> > policies. ie Component A declares a dependency on Role P. If
> > there is only
> > one P in the system then that P will be used - however if
> > there is multiple
> > Ps in the system (namely x, y and z) then one of them will be
> > selected
> > based on a heuristic that takes a policy (aka a hint).
> >
> > The difference between Merlins model and the Cocoon model is
> > that in Cocoon
> > the metainfo (ie hint) is stored in code while in Merlin it
> > is stored in
> > descriptor (aka a .xinfo file).
>
> Another key difference is that the Cocoon model has a requirement
> to re-connect the hint mappings at runtime--whereas the Merlin
> model does it all at init time.
Can you explain that? You aquire components based on request parameters but
the request parameters supply constraints and not hints (ie "ssl" vs
"xalan").
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> This is very very similar to what Stephen is doing in Merlin wrt to
> policies. ie Component A declares a dependency on Role P. If
> there is only
> one P in the system then that P will be used - however if
> there is multiple
> Ps in the system (namely x, y and z) then one of them will be
> selected
> based on a heuristic that takes a policy (aka a hint).
>
> The difference between Merlins model and the Cocoon model is
> that in Cocoon
> the metainfo (ie hint) is stored in code while in Merlin it
> is stored in
> descriptor (aka a .xinfo file).
Another key difference is that the Cocoon model has a requirement
to re-connect the hint mappings at runtime--whereas the Merlin
model does it all at init time.
And that is the real world solution I want to solve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> > Leo Sutic wrote:
<snip/>
> > > /**
> > > * Issues:
> > > *
> > > * - Should it throw Exceptions on failed lookup or return null?
> > > * - Should it exist at all?
> > > * - Should the hint be a String?
> > > */
> > > public Object lookup (String role, Object hint);
> > >}
> >
> > Two questions here.
> > 1. Do you have examples of cases where the role and hint
> > cannot reasonably be expressed as an opaque string ?
>
> Cocoon selects based on HttpServletRequest. Sure, as the
Minor correction: Based on *state* of the system. This is composition of
Context, Request, Session, and whatever you wrote by yourself.
> request is a stream of characters coming in on a socket,
> you can send that string on, but it is ugly ugly ugly.
<snip/>
Vadim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> Leo Sutic wrote:
>
> >All,
> >
> >this is my understanding of the sort-of concensus we have
> arrived at.
> >Some issues are still being debated, and I believe I have
> marked those
> >as such.
> >
> >The ComponentManager interface:
> >
> >interface ComponentManager {
> > /**
> > * Issues:
> > *
> > * - Should it throw Exceptions on failed lookup or return null?
> > */
> > public Object lookup (String role);
> >
>
> My preference is for the maintenace of the current exception
> declaration.
Mine too. (Fail-fast).
> > /**
> > * Issues:
> > *
> > * - Should it throw Exceptions on failed lookup or return null?
> > * - Should it exist at all?
> > * - Should the hint be a String?
> > */
> > public Object lookup (String role, Object hint);
> >}
> >
>
> Two questions here.
> 1. Do you have examples of cases where the role and hint
> cannot reasonably be expressed as an opaque string ?
Cocoon selects based on HttpServletRequest. Sure, as the
request is a stream of characters coming in on a socket,
you can send that string on, but it is ugly ugly ugly.
> 2. If a hint value is required - could it be formalized into a typed
> structure that could be built by a generic kernel?
I do not think so. Hints are too tightly coupled to the
ComponentSelectors, and come in too many forms.
> >We've agreed on removing release() from the CM interface,
> and the rest
> >of this sumary details how we get the same functionality
> without that
> >method.
> >
> >We've agreed that all components returned from a CM are thread safe.
> >
> >Borrowing from Robert Mouat's mail:
> >
> >transaction:
> >
> > this is the period during which a component can be
> expected to hold
> > a [non-memory] resource. This depends a lot on the interface, and
> > I'm going to divide these into 3 categories:
> >
> > 1. The interface defines no transaction. e.g. those that can be
> > implemented in a thread-safe manner. e.g.
> >
> > interface DocumentStore
> > {
> > public Document getDocument( String ref );
> > public void putDocument( String ref, Document doc );
> > }
> >
> > 2. The interface has its own transaction delineators.
> > e.g. open/close, or begin/end. These clearly define when the
> > transaction begins and ends, and there is no reason to
> suspect that a
> > component holds any resources after the close/end method is
> called.
> > [Since I'm really only considerating the end of the
> transaction only
> > the close/end method is needed]. An example of this would
> be a SAX
> > Transformer with its startDocument/endDocument methods, or a
> > non-component example might be a java.io.InputStream with
> its close
> > method.
> >
> > 3. Finally there are interfaces which imply a transaction
> (i.e. that
> > the implementation may need to hold resources), but do not
> have any
> > methods delineating the transaction. The only example I
> can think of
> > for this one is not a component but the java.util.Iterator,
> which has
> > a next() method but no ending method.
> >
> >(end quote)
> >
> >------------------
> >TYPE 1:
> >
> >Components of type 1 are looked up directly:
> >
> >public class MyComposer implements Composable {
> >
> > private DocumentStore store = null;
> >
> > public void compose (ComponentManager manager) {
> > store = (DocumentStore) manager.lookup (DocumentStore.ROLE);
> > }
> >}
> >
> >Components of type 1 are never released. A client keeps a
> reference to
> >it for the duration of its lifetime.
> >
> >I believe we have concensus on this.
> >
> >------------------
> >TYPES 2 and 3:
> >
> >Components of type two and three are not looked up directly:
> >
> >public class MyComposer implements Composable {
> >
> > private TransformerManager transformerManager = null;
> >
> > public void compose (ComponentManager manager) {
> > transformerManager = (TransformerManager) manager.lookup
> >(TransformerManager.ROLE);
> > }
> >
> > public void doStuff () {
> > Transformer transformer =
> transformerManager.getTransformer ();
> > try {
> > } finally {
> > transformerManager.release (transformer);
> > // OR
> > transformer.release();
> > // OR
> > transformer.endDocument();
> > }
> > }
> >}
> >
>
> I'm assuming that TransformerManager is defined as a
> component and declared as a dependent of MyComposer.
Yes.
> Operations relating to release/endDocument etc. are
> non-lifecycle interfaces (i.e. there are service interfaces
> declared by the TransformerManager component).
Yes.
> >As seen above, for components whose interface makes them
> thread-unsafe,
> >
>
> Is it interface, implementation, or meta that declares
> non-thread-safe ? I'm presuming this would be handled with a
> service attribute at the
> meta-level.
I mean for interfaces that implies state. Such as a SAX transformer
component. You'd look it up and then get a ContentHandler interface.
Since the methods must be called in a certain order, the SAX
transformer component can not return the same transformer instance.
The thread-unsafety is not declared, but rather a property of the
way the client is supposed to interact with the component.
> > + For components of this type selected with a hint, we still
> > get the ugly two-step lookup we have with ComponentSelectors.
> >
>
> Can you go into this further.
Well, if we take the current CM interface and use selectors (CS):
ComponentSelector cs = (ComponentSelector) manager.lookup (Comp.ROLE +
"Selector")
Comp comp = (Comp) cs.select (hint);
comp.doStuff ();
cs.release (comp);
manager.release (cs);
Now, add a lookup(String,Object) to A4 CM interface:
Comp comp = (Comp) manager.lookup (Comp.ROLE, hint);
comp.doStuff ();
manager.release (cs);
Neater, right?
But with the factory approach we have now:
CompManager cmanager = (CompManager) manager.lookup (CompManager.ROLE,
hint)
comp = cmanager.getInstance ();
comp.doStuff ();
cmanager.release (comp);
> I'm right now loking at selection
> policies concerning the case where multiple component candidates are
> presented based on metainfo declarations. I would really like to
> know/understand if this is a real runtime issues (i.e. the actual
> selection criteria is reflected in the request state of the
> component)
If do not completely follow you here.
> or if this can be handeled at the type level.
>
> >
> >
> > + A XXXXManager interface and a corresponding implementation is
> > needed for each type 2 and 3 component == more code to write.
> >
>
> Would the XXXXManager interface typically be something like
> the current
> CM interface or would it be more like the mpool.Pool interface ... or
> more typically something custom ?
Leaving that open. See my email to Carsten of about an hour ago... I
foresee that it will be *very* similar to the current CM interface,
on the grounds that it makes the framework easier to use.
What we have done is basically exposed the ComponentHandlers of A4
ECM.
So as it stands now, we have increased flexibility, satisfied some
architectural issues, and I think we have a good migration path.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo:
Thanks for the overview.
I've included a bunch of in-line comments - most to do with pulling
out extra information concerning the way this is going to be used, and
a couple of commonts on preferences I have in certain areas.
Leo Sutic wrote:
>All,
>
>this is my understanding of the sort-of concensus we have arrived at.
>Some issues are still being debated, and I believe I have marked those
>as such.
>
>The ComponentManager interface:
>
>interface ComponentManager {
> /**
> * Issues:
> *
> * - Should it throw Exceptions on failed lookup or return null?
> */
> public Object lookup (String role);
>
My preference is for the maintenace of the current exception declaration.
>
>
> /**
> * Issues:
> *
> * - Should it throw Exceptions on failed lookup or return null?
> * - Should it exist at all?
> * - Should the hint be a String?
> */
> public Object lookup (String role, Object hint);
>}
>
Two questions here.
1. Do you have examples of cases where the role and hint cannot reasonably
be expressed as an opaque string ?
2. If a hint value is required - could it be formalized into a typed
structure that could be built by a generic kernel?
>
>
>We've agreed on removing release() from the CM interface, and the rest
>of this sumary details how we get the same functionality without
>that method.
>
>We've agreed that all components returned from a CM are thread safe.
>
>Borrowing from Robert Mouat's mail:
>
>transaction:
>
> this is the period during which a component can be expected to hold
> a [non-memory] resource. This depends a lot on the interface, and
> I'm going to divide these into 3 categories:
>
> 1. The interface defines no transaction. e.g. those that can be
> implemented in a thread-safe manner. e.g.
>
> interface DocumentStore
> {
> public Document getDocument( String ref );
> public void putDocument( String ref, Document doc );
> }
>
> 2. The interface has its own transaction delineators.
> e.g. open/close, or begin/end. These clearly define when the
> transaction begins and ends, and there is no reason to suspect that
> a component holds any resources after the close/end method is
> called. [Since I'm really only considerating the end of the
> transaction only the close/end method is needed]. An example of
> this would be a SAX Transformer with its startDocument/endDocument
> methods, or a non-component example might be a java.io.InputStream
> with its close method.
>
> 3. Finally there are interfaces which imply a transaction (i.e. that
> the implementation may need to hold resources), but do not have any
> methods delineating the transaction. The only example I can think
> of for this one is not a component but the java.util.Iterator, which
> has a next() method but no ending method.
>
>(end quote)
>
>------------------
>TYPE 1:
>
>Components of type 1 are looked up directly:
>
>public class MyComposer implements Composable {
>
> private DocumentStore store = null;
>
> public void compose (ComponentManager manager) {
> store = (DocumentStore) manager.lookup (DocumentStore.ROLE);
> }
>}
>
>Components of type 1 are never released. A client keeps a reference
>to it for the duration of its lifetime.
>
>I believe we have concensus on this.
>
>------------------
>TYPES 2 and 3:
>
>Components of type two and three are not looked up directly:
>
>public class MyComposer implements Composable {
>
> private TransformerManager transformerManager = null;
>
> public void compose (ComponentManager manager) {
> transformerManager = (TransformerManager) manager.lookup
>(TransformerManager.ROLE);
> }
>
> public void doStuff () {
> Transformer transformer = transformerManager.getTransformer ();
> try {
> } finally {
> transformerManager.release (transformer);
> // OR
> transformer.release();
> // OR
> transformer.endDocument();
> }
> }
>}
>
I'm assuming that TransformerManager is defined as a component and
declared as a dependent of MyComposer. Operations relating to
release/endDocument etc. are non-lifecycle interfaces (i.e. there
are service interfaces declared by the TransformerManager component).
>
>
>As seen above, for components whose interface makes them thread-unsafe,
>
Is it interface, implementation, or meta that declares non-thread-safe ?
I'm presuming this would be handled with a service attribute at the
meta-level.
>
>there *must* be a method, either in the associated manager, or in the
>component itself, that, when called by the client, indicates that
>the client is finished using the component.
>
>I believe we have concensus on this.
>
>(end summary)
>
>--------------------------------------------
>
>Implications of Type 1 (my own thoughts, no concensus on this):
>
> + As there is no release() or equivalent,
>
Agreed.
>the implementation is
> restricted to only holding resources during method invokations.
>
I agree in principal - but (a) this is one of those things you/I/we have
no control over and (b) the term resource is open to interpritation. But
this is neither here nor there...
>
>
> + All implementations must be thread safe.
>
+1
>
>
>
>Implications of types 2 and 3 (my own thoughts, no concensus on this):
>
> + As there is a release() or equivalent, the implementation may
> hold resources during the entire transaction.
>
+1
>
>
> + Implementations may be thread safe, but need not be.
>
It's an implementation issue.
>
>
> + For components of this type selected with a hint, we still
> get the ugly two-step lookup we have with ComponentSelectors.
>
Can you go into this further. I'm right now loking at selection
policies concerning the case where multiple component candidates are
presented based on metainfo declarations. I would really like to
know/understand if this is a real runtime issues (i.e. the actual
selection criteria is reflected in the request state of the component)
or if this can be handeled at the type level.
>
>
> + A XXXXManager interface and a corresponding implementation is
> needed for each type 2 and 3 component == more code to write.
>
Would the XXXXManager interface typically be something like the current
CM interface or would it be more like the mpool.Pool interface ... or
more typically something custom ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [summary] declared vs runtime vs no exceptions
Posted by Peter Donald <pe...@apache.org>.
At 06:31 PM 6/12/2002 +0200, you wrote:
> > >IOW, no changes neccessary.
> > >
>
>
>If this means that we keep it as it is now (not as it is in my summary),
>then +1.
+1
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [summary] declared vs runtime vs no exceptions
Posted by Leo Simons <le...@apache.org>.
> >thought:
> >It could be nice to formalize the way we handle exceptions (like the XML
> >Axis project) a little more.
> >
>
> Can you expand on this ?
> (for those of us too lazy to surf)
> :-)
Apache Axis (over at XML) has a really big developer's guide:
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/developers-guide.html
among which is some stuff about exceptions:
http://cvs.apache.org/viewcvs.cgi/~checkout~/
xml-axis/java/docs/developers-guide.html#Exception Handling
(note: wrapped link)
Some of this is applicable to all software (and we could copy or
reference), some only to Axis.
Basically, we could have a "recommended avalon programming practices"
page, which describes the way IoC/SoC and the exception mechanism work
together.
stuff like:
Everything a container (is this a good idea for composer?) passes to a
child component should only throw exceptions which the container
(composer?) knows about, so the child component has the option to send
the exception back to the container. This enables rapid prototyping of
components.
In code, it looks like this:
interface SomeComponentInterface
{
public someMethod( SomeSpecificObjectInterface ) throws
SomeComponentException;
}
interface SomeSpecificObjectInterface
{
public Something someMethod() throws SomeMethodException;
// or just SomecomponentException
}
interface Something {}
class SomeComponentException extends Exception {}
class SomeMethodException extends SomeComponentException {}
class SomeComponent implements SomeComponentInterface
{
Something m_something;
public someMethod( SomeSpecificObjectInterface obj )
throws SomeComponentException
{
m_something = obj.someMethod();
// no try/catch neccessary
}
}
Examples of this setup within avalon framework can be found in the
Composable/ComponentManager/ComponentException and the
Contextualizable/Context/ContextException interfaces and classes.
---
There's lots of stuff like that, usage scenario's like JavaBeans, which
we don't enforce, don't mention, don't document, but still use. It's not
required to work with avalon, but it can be quite useful.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [summary] declared vs runtime vs no exceptions
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> >IOW, no changes neccessary.
> >
If this means that we keep it as it is now (not as it is in my summary),
then +1.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [summary] declared vs runtime vs no exceptions
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>one of the points of debate left after Leo Sutic's summary of the A5 CM
>discussion is that of exception throwing.
>
>
>
>>The ComponentManager interface:
>>
>>interface ComponentManager {
>> /**
>> * Issues:
>> *
>> * - Should it throw Exceptions on failed lookup or return null?
>> */
>> public Object lookup (String role);
>>
>>
>
>This is a broader topic: many of the classes related to the lifecycle
>interface methods (ComponentManager, Context, ...) throw (specialized,
>declared, non-runtime exceptions).
>
>Summary
>=======
>Stefano raised this issue, stating that unnecessary exception throwing
>slows an application down; which Leo Sutic refuted
>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102369972301164&w=2).
>
>Furthermore, the burden imposed on component developers was mentioned as
>they'll have to write try/catch/finally statements, where it would be
>more convenient to have RuntimeExceptions as those do not have to be
>caught.
>In cases where finally{} is not necessary, this is not true, as the
>component developer can usually opt to not to catch the exception and
>have it cascade back to the container (ie, ComponentManager.lookup()
>called within compose() does not have to be surround by try{} in that
>case as compose() throws the same exception as lookup).
>
>The question here (#1): is it desirable to impose a burden like this
>(which is not *that* big) on component developers?
>
Its desirable.
>- If the answer is no, then a RuntimeException is an alternative.
>
>It has also been argued that exceptions should only be used in
>"exceptional" circumstances, and that a lookup failing is not
>exceptional, but can sometimes be expected.
>
>The question here (#2): where is it an "exception" to have a method
>fail, and where is it really "normal" behaviour that should be
>communicated in a different way?
>
I'm not aware of any areas of issue.
I consider modification of the exceptiuon usage as unnecesary revision
to the framework interfaces and would be opposed to the idea based on
information provided todate.
>
>- In cases where we really deal with "normal" behaviour, the only other
>viable communication option is to return null, resulting in either a
>test against null, or a NullPointerException.
>
>my answers:
>#1 - generally, yes. The alternative is to either have them not know
>(RuntimeException) which will possibly lead to memory leaks, or to have
>them deal with a possible return of "null"
>
>#2 - I can't think of places in avalon framework where an exception is
>thrown while there is no true exception; it would still be good to
>evaluate this.
>
>IOW, no changes neccessary.
>
+1
>
>thought:
>It could be nice to formalize the way we handle exceptions (like the XML
>Axis project) a little more.
>
Can you expand on this ?
(for those of us too lazy to surf)
:-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[summary] declared vs runtime vs no exceptions
Posted by Leo Simons <le...@apache.org>.
one of the points of debate left after Leo Sutic's summary of the A5 CM
discussion is that of exception throwing.
> The ComponentManager interface:
>
> interface ComponentManager {
> /**
> * Issues:
> *
> * - Should it throw Exceptions on failed lookup or return null?
> */
> public Object lookup (String role);
This is a broader topic: many of the classes related to the lifecycle
interface methods (ComponentManager, Context, ...) throw (specialized,
declared, non-runtime exceptions).
Summary
=======
Stefano raised this issue, stating that unnecessary exception throwing
slows an application down; which Leo Sutic refuted
(http://marc.theaimsgroup.com/?l=avalon-dev&m=102369972301164&w=2).
Furthermore, the burden imposed on component developers was mentioned as
they'll have to write try/catch/finally statements, where it would be
more convenient to have RuntimeExceptions as those do not have to be
caught.
In cases where finally{} is not necessary, this is not true, as the
component developer can usually opt to not to catch the exception and
have it cascade back to the container (ie, ComponentManager.lookup()
called within compose() does not have to be surround by try{} in that
case as compose() throws the same exception as lookup).
The question here (#1): is it desirable to impose a burden like this
(which is not *that* big) on component developers?
- If the answer is no, then a RuntimeException is an alternative.
It has also been argued that exceptions should only be used in
"exceptional" circumstances, and that a lookup failing is not
exceptional, but can sometimes be expected.
The question here (#2): where is it an "exception" to have a method
fail, and where is it really "normal" behaviour that should be
communicated in a different way?
- In cases where we really deal with "normal" behaviour, the only other
viable communication option is to return null, resulting in either a
test against null, or a NullPointerException.
my answers:
#1 - generally, yes. The alternative is to either have them not know
(RuntimeException) which will possibly lead to memory leaks, or to have
them deal with a possible return of "null"
#2 - I can't think of places in avalon framework where an exception is
thrown while there is no true exception; it would still be good to
evaluate this.
IOW, no changes neccessary.
thought:
It could be nice to formalize the way we handle exceptions (like the XML
Axis project) a little more.
regards,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
> I figure that is what will happen, too. The need is so obvious.
Ok, this might get to
stefano = (Idiot) avalon-dev.lookup(Idiot.ROLE);
or even better ;-)
stefano = (Person) avalon-dev.lookup(Person.ROLE,"idiot");
but there is *NOTHING* obvious to me in all this discussions. :/
Probably I simply lack context, but could you please indicate along with
the changes *why* you are proposing them?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > + All implementations must be thread safe.
>
> thought: in a simple singlethreaded use of the framework,
> thread safety is not something to be concerned about. It'd be
> nice to not require a lot of work in this kind of setup.
> Should be possible.
I'm fine with that.
> > + A XXXXManager interface and a corresponding implementation is
> > needed for each type 2 and 3 component == more code to write.
>
> yup, but that code can be within avalon == all but completely
> transparant to component developer. Right?
Something like what I described to Carsten?
I figure that is what will happen, too. The need is so obvious.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> this is my understanding of the sort-of concensus we have arrived at.
it is my understanding too.
> Some issues are still being debated, and I believe I have marked those
> as such.
Yep.
<snip summary />
some more thoughts:
> Implications of Type 1 (my own thoughts, no concensus on this):
>
> + As there is no release() or equivalent, the implementation is
> restricted to only holding resources during method invokations.
+1, only by contract though, no way to enforce this
> + All implementations must be thread safe.
thought: in a simple singlethreaded use of the framework, thread safety
is not something to be concerned about. It'd be nice to not require a
lot of work in this kind of setup. Should be possible.
> Implications of types 2 and 3 (my own thoughts, no concensus on this):
>
> + As there is a release() or equivalent, the implementation may
> hold resources during the entire transaction.
+1
> + Implementations may be thread safe, but need not be.
+1
> + For components of this type selected with a hint, we still
> get the ugly two-step lookup we have with ComponentSelectors.
yup.
> + A XXXXManager interface and a corresponding implementation is
> needed for each type 2 and 3 component == more code to write.
yup, but that code can be within avalon == all but completely
transparant to component developer. Right?
this is a fruitful discussion...Berin and Pete have been at it for ages;
looks like there is finally some progress =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 03:00 PM 6/12/2002 +0200, you wrote:
>><component role="org.ziegeler.CarstensComponent"
>> class="Avalon4Factory"
>> avalon-4-class="org.ziegeler.CarstensA4Component"
>> pool-min="2"
>> pool-max="4"/>
>
>Leo:
>
>Any chance I can get you to translate this into an equivalent xinfo
>component/block defintion ? I'm not familiar with Excalibur component defs
>and the role together with class and attribites is thowing me (i'm use to
>the .xinfo roles on the consumer's dependency declation and class by
><classname>.xinfo).
There is no direct equivelent. Role ~= Service, avalon-4-class == <classname>
org/ziegeler/CarstensA4Component.xinfo:
<blockinfo>
<block>...</block>
<services><service name="org.ziegeler.CarstensComponent"/></services>
</blockinfo>
However the component is accessed via a factory, so in phoenix terms each
block who depends on this block would get a new instance of the component
from pool and the pool would use objectFactory Avalon4Factory. The pool
would have min of 2 items and max of 4 (however this irrelevent in phoenix
as they are never released till end of components lifecycle).
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
>
>
><component role="org.ziegeler.CarstensComponent"
> class="Avalon4Factory"
> avalon-4-class="org.ziegeler.CarstensA4Component"
> pool-min="2"
> pool-max="4"/>
>
Leo:
Any chance I can get you to translate this into an equivalent xinfo
component/block defintion ? I'm not familiar with Excalibur component
defs and the role together with class and attribites is thowing me (i'm
use to the .xinfo roles on the consumer's dependency declation and class
by <classname>.xinfo).
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> > Would work, but if that's the case, I have to implement a
> > "factory", the parser itself (including the "factory"
> > interface, the parser interface) etc. and I don't see the
> > great advantage in using a component framework anymore as I
> > code most part myself.
> >
> > Am I wrong?
>
> Carsten,
>
> you got it right. Those are exactly the implications of the
> proposal.
>
> Now for the good parts: The factory can be generic.
> So I code up a PooledFactory that takes your component class
> as a parameter, and bam there we go.
>
> The only change is that you'll have to grab the factories
> out of the ComponentManager in the compose() method:
>
> <component role="org.ziegeler.CarstensComponent"
> class="Avalon4Factory"
> avalon-4-class="org.ziegeler.CarstensA4Component"
> pool-min="2"
> pool-max="4"/>
>
> ...
>
> public class CarstensComposer {
>
> A4Factory carstenFactory;
>
> public void compose (ComponentManager manager) {
> carstenFactory = (A4Factory) manager.lookup
> (org.ziegeler.CarstensComponent.ROLE);
> }
>
> public void doStuff () {
> CarstensComponent comp = (CarstensComponent)
> carstenFactory.getInstance ();
> try {
> comp.doStuff ();
> } finally {
> carstenFactory.release (comp);
> }
> }
> }
>
> Look at the configuration snippet, and replace "class" with
> "handler-class" and "avalon-4-class" with "class" and you get
> the idea.
>
> ..or am I trying to do the impossible here?
Ok, but *WHY*?
I have a gut feeling that you'll need *STONG* arguments (or a bunch of
time to volunteer) to make the cocoon-dev community buy that.
Moreover, I was told that Component was changed to Object to allow
non-avalon stuff to be returned by the CM and now you force these to be
thread-safe?
These two solutions tend to push in different directions, IMHO.
Please, explain.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> > ..or am I trying to do the impossible here?
>
> Yes, this should work, but I don't see the real advantage of it.
> Now, a component framework should make working with components
> very easy. As a client (or Composer) I personally don't want to
> care about ThreadSafe or not (that is in my eyes one of the
> big advantages of the current 4.x implementation, although there
> are some other problems...).
> Now, if I want to lookup a component, I have to know if it is
> ThreadSafe or not. If it is ThreadSafe I directly get the component
> on lookup - if not, I get a "factory" and need a second method call
> on this factory to get the real component.
>
> And I believe that the client a) should not care about this implementation
> detail and b) in some cases even might not know about it.
Amen!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 04:30 PM 6/12/2002 +0200, you wrote:
>
>>> Yes, and this is the thing that worries me - I know a lot of people
>>> saying "Avalon is too complicated" and this makes it even a little
>>> bit more complicated,
>>
>>
>> Actually I have quite the opposite view. I belive that what is
>> happending at the moment is equivilent to ironing out the wrinkes on
>> an excellant tapestry. When those wrinkles dissaper you will see
>> more and more value as tools converge toward a common model,
>
>
> Say like agreeing that rolename = classname + decoration?
>
> /me ducks and runs
>
> :)
A wise and pragmatic move!
:-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 04:30 PM 6/12/2002 +0200, you wrote:
>>Yes, and this is the thing that worries me - I know a lot of people
>>saying "Avalon is too complicated" and this makes it even a little
>>bit more complicated,
>
>Actually I have quite the opposite view. I belive that what is happending
>at the moment is equivilent to ironing out the wrinkes on an excellant
>tapestry. When those wrinkles dissaper you will see more and more value
>as tools converge toward a common model,
Say like agreeing that rolename = classname + decoration?
/me ducks and runs
:)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > > Leo Sutic wrote:
> > > > Carsten,
> > > >
> > > > you are right - everything gets a little bit more complicated.
> > > >
> > > Yes, and this is the thing that worries me - I know a lot of people
> > > saying "Avalon is too complicated" and this makes it even a
> > little bit
> > > more complicated,
> >
> > hmm. Is it more complicated?
>
> As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> come from the "pattern hell" school of thought. (That was a point
> against Cocoon, if anyone missed it.)
>
> Worth thinking about, as I have seen some people here accusing
> Cocoon of not following patterns cleanly enough.
>
> As a matter of fact, I think we scare the shit out of most people
> with the complexity of the framework already. Patterns within
> patterns... It is not whether there are patterns or not - it is
> the fact that you have patterns of patterns, and you must somehow
> grasp them all.
>
> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not committed
> to API stability, (2) just about when we've finally learned to use
> the framework (given how complex it is that may be a while), the next
> change will come along, (3) the cost of maintenance and keeping up
> with that will kill us. Let's roll our own framework."
>
> If it is more complicated or not does not matter - what matters is
> what it is *percieved* as.
>
> For all its faults, A4 is *easy* to *use*. (Although I confess I never
> ever understood the RoleManager.)
Everytime you make a new generation of a project you are actually
forking the community without knowing.
So, either you are able to attract users and developers to the new
generation, or you are actually creating a new project: A4 and A5 which
just look like different highways going in different directions (in
italy we name highways with the A* pattern)
I first did this when I started JServ 1.0.x vs JServ 0.9.x, then I did
it with Cocoon 1.x vs Cocoon 2.x... I'm *NOT* going to do it again. It's
too painful, too risky and too expensive in time and energy for me and
for the community in general.
I understand that you can't patch A4 without breaking compatibility.
But *please* make all efforts to make A5 *easier* to learn, to use and
to appreciate than A4 or you will be in fact killing Avalon as a result
of your actions.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 11:03 AM 6/12/2002 -0400, you wrote:
>
>> * The ComponentManager (should it be ComponentDirectory?) is used
>> by a client to gain access to other components.
>
>
>
> +1000000000000000000000000000000000000000
But directories imply an index.
Maybe ComponentLocator is the word you looking for.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 11:03 AM 6/12/2002 -0400, you wrote:
>* The ComponentManager (should it be ComponentDirectory?) is used
> by a client to gain access to other components.
+1000000000000000000000000000000000000000
The thing that is most confusing about Avalon is that the containers
>do things differently--and we need to unify the approach. This is
>a _simplification_, not anything more complex. Currently the way
>we represent meta-data is all over the place. Fortress/ECM use a
>RoleManager, Phoenix uses component info (.xinfo) files, etc.
Slowly getting to something capable of representing what we need IMHO.
>
> > For all its faults, A4 is *easy* to *use*. (Although I
> > confess I never ever understood the RoleManager.)
>
>
>Leo, the RoleManager is not a Framework thing--it is used in both
>ECM and Fortress.
Myrmidon also uses a RoleManager ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Let's get real: let's make Avalon 5 the real stable Avalon
(was Re: [Summary] Avalon 5 ComponentManager interface)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>
> I agree with your vision, I think, but I'd like you to
> specify exactly what that vision means in terms of Avalon code:
> What interfaces do we change, and how? What else needs to change,
> and how?
>
> That said, I think we do need a bit more user-orientation and less
> obsessiveness about what consitutes "good architecture" and "proper
> SoC, IoC" and other fancy terms... Sometimes I think we're getting
> a bit overboard and justify our architecture with statements regarding
> what we consider "good architecture/philosophy etc." and not in terms of
> how good and useful for our users. If this is the "less wanking" point
> on Nicola's list, then I am
>
> +1
>
> just for that reason. I think we risk building all these air castles
> that no one will ever find useful irrespective of how mathematically
> or academically correct they may be unless we start checking ourselves.
I will send you my mails to you personally next time, you make a
wonderful job in explaining :-D
Sometimes I wonder how I get to write so convoluted stuff :-/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Let's get real: let's make Avalon 5 the real stable Avalon (was Re: [Summary] Avalon 5 ComponentManager interface)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> You know what?
> I would REALLY like to see AF 5 be a big fat bugfix release
> with regards
> to A4.
>
> That is:
> - real-life examples, with ready to use containers (Merlin,
> Phoenix, etc)
> - better interfaces, like the Service ones, based on real life needs
> (not only mental masturbations)
> - Examples, examples, examples, examples
> - Usecases, usecases, usecases, usecases
> - Documentation with images, images, images, images
>
> It will have to *look* new, but will be what AF4 wshould have
> been all way long.
>
> If we change interfaces too much again we will loose our
> users. We will. Believe me. Many told me.
>
> This is not a rant but a proposal.
> I want to see votes on this proposal, because we are playing with the
> life of this project.
OK - can you rewrite your points as a proposal. That is, what
exactly is it you are proposing? Especially "better interfaces"
is a bit vague in combination with "If we change interfaces too
much again we will loose our users."
I agree with your vision, I think, but I'd like you to
specify exactly what that vision means in terms of Avalon code:
What interfaces do we change, and how? What else needs to change,
and how?
That said, I think we do need a bit more user-orientation and less
obsessiveness about what consitutes "good architecture" and "proper
SoC, IoC" and other fancy terms... Sometimes I think we're getting
a bit overboard and justify our architecture with statements regarding
what we consider "good architecture/philosophy etc." and not in terms of
how good and useful for our users. If this is the "less wanking" point
on Nicola's list, then I am
+1
just for that reason. I think we risk building all these air castles
that no one will ever find useful irrespective of how mathematically
or academically correct they may be unless we start checking ourselves.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Let's get real: let's make Avalon 5 the real stable Avalon
(was Re: [Summary] Avalon 5 ComponentManager interface)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>
>>From: Leo Simons [mailto:leosimons@apache.org]
>>
>>
>>>Leo Sutic wrote:
>>>
>>>>Carsten,
>>>>
>>>>you are right - everything gets a little bit more complicated.
>>>>
>>>
>>>Yes, and this is the thing that worries me - I know a lot of people
>>>saying "Avalon is too complicated" and this makes it even a
>>
>>little bit
>>
>>>more complicated,
>>
>>hmm. Is it more complicated?
>
>
> As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> come from the "pattern hell" school of thought. (That was a point
> against Cocoon, if anyone missed it.)
And against Avalon.
It's so easy, that it's too hard (not a joke).
> Worth thinking about, as I have seen some people here accusing
> Cocoon of not following patterns cleanly enough.
>
> As a matter of fact, I think we scare the shit out of most people
> with the complexity of the framework already. Patterns within
> patterns... It is not whether there are patterns or not - it is
> the fact that you have patterns of patterns, and you must somehow
> grasp them all.
Correct.
After a week of teaching Avalon, I showed 2 implementation classes.
They said "is it this? easy!".
Users are better off seeing it's easy and that it works for them rather
that being told how it was concieved.
> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not committed
> to API stability, (2) just about when we've finally learned to use
> the framework (given how complex it is that may be a while), the next
> change will come along, (3) the cost of maintenance and keeping up
> with that will kill us. Let's roll our own framework."
(1) Berin can say anything ;-P but stability was never seen in Avalon (bad)
(2) And Berin will say it's a new version, we don't need to be
compatible (ie deprecation)
(3) Seen that, been there, heard it. It's true.
> If it is more complicated or not does not matter - what matters is
> what it is *percieved* as.
>
> For all its faults, A4 is *easy* to *use*. (Although I confess I never
> ever understood the RoleManager.)
You know what?
I would REALLY like to see AF 5 be a big fat bugfix release with regards
to A4.
That is:
- real-life examples, with ready to use containers (Merlin, Phoenix, etc)
- better interfaces, like the Service ones, based on real life needs
(not only mental masturbations)
- Examples, examples, examples, examples
- Usecases, usecases, usecases, usecases
- Documentation with images, images, images, images
It will have to *look* new, but will be what AF4 wshould have been all
way long.
If we change interfaces too much again we will loose our users.
We will. Believe me. Many told me.
This is not a rant but a proposal.
I want to see votes on this proposal, because we are playing with the
life of this project.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> Hmmm, simply by stating that every component must be ThreadSafe, you are
> forcing every project that uses A4 to implement a ton of shitty glue
> code around those inherently thread-unsafe components, just to satisfy
> your elegance needs.
nope. The thread safety can be mostly addressed by avalon, outside of
the CM interface.
Also, we are not stating that every component must be thread safe, only
that it must be thread safe if it doesn't define a way to release
resources itself.
> > > If it is more complicated or not does not matter - what matters is
> > > what it is *percieved* as.
> >
> > yup.
> >
> > Another thought: having users on a development list means we will have
> > more perceptions like this. Having a user list would remove some of
> > these concerns.
>
> if avalon developers perceive it as more complicated, I can't guess what
> users will think about it :)
oh, but the users will just see a utility to convert existing stuff from
A4 to A5, compatibility mode, and a clear explanation with examples of
why the change was made. The developers just get an interface
declaration =)
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
>
> > > > > you are right - everything gets a little bit more complicated.
> > > > >
> > > > Yes, and this is the thing that worries me - I know a lot of people
> > > > saying "Avalon is too complicated" and this makes it even a
> > > little bit
> > > > more complicated,
> > >
> > > hmm. Is it more complicated?
> >
> > As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> > come from the "pattern hell" school of thought. (That was a point
> > against Cocoon, if anyone missed it.)
> >
> > Worth thinking about, as I have seen some people here accusing
> > Cocoon of not following patterns cleanly enough.
> >
> > As a matter of fact, I think we scare the shit out of most people
> > with the complexity of the framework already.
>
> yup. Which is why it would be good to make it simpler, which I believe
> these changes will do, as I tried to point out.
If even a single committer on this list disagrees, I smell troubles.
Here you have two/three (Berin, Carsten and myself). Interesting enough
Cocoon is the biggest and most used project that uses Avalon and we
represent that community.
Of course we don't want to veto anything as we are here to help and to
shape A5 so that everyone is happy, but it should definately ring a
bell.
> > Patterns within
> > patterns... It is not whether there are patterns or not - it is
> > the fact that you have patterns of patterns, and you must somehow
> > grasp them all.
>
> "patterns of patterns" ... that's a good way to describe it =)
I sometimes used the term 'metapattern' to describe IoC and SoC. In
fact, MVC implements SoC.
> I got started with avalon by writing a nifty horror called XCommander.
> I'm quite sure I didn't understand all of those patterns then, though.
>
> We should separate what you need to grasp to work with avalon, and what
> you need to know to work with it perfectly. Just like there's many
> levels of java programming skill (you don't need to know clasloaders to
> write an applet that does tic tac toe).
>
> > So I completely understand Carsten. We will lose users. I see
> > before me someone saying "F*** it. (1) They are obviously not committed
> > to API stability, (2) just about when we've finally learned to use
> > the framework (given how complex it is that may be a while), the next
> > change will come along, (3) the cost of maintenance and keeping up
> > with that will kill us. Let's roll our own framework."
>
> yup. The thing to do is to change this perception so that it is clear
> that (1) is not true, that the changes in (2) will make using the
> framework both easier and simpler in the end, and to be very sure that
> (3) will also not happen (ie backwards compatibility in a realistic
> way).
Hmmm, simply by stating that every component must be ThreadSafe, you are
forcing every project that uses A4 to implement a ton of shitty glue
code around those inherently thread-unsafe components, just to satisfy
your elegance needs.
Talking about ways to piss people off, this seems like a great one to
me.
> > If it is more complicated or not does not matter - what matters is
> > what it is *percieved* as.
>
> yup.
>
> Another thought: having users on a development list means we will have
> more perceptions like this. Having a user list would remove some of
> these concerns.
if avalon developers perceive it as more complicated, I can't guess what
users will think about it :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > > > you are right - everything gets a little bit more complicated.
> > > >
> > > Yes, and this is the thing that worries me - I know a lot of people
> > > saying "Avalon is too complicated" and this makes it even a
> > little bit
> > > more complicated,
> >
> > hmm. Is it more complicated?
>
> As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> come from the "pattern hell" school of thought. (That was a point
> against Cocoon, if anyone missed it.)
>
> Worth thinking about, as I have seen some people here accusing
> Cocoon of not following patterns cleanly enough.
>
> As a matter of fact, I think we scare the shit out of most people
> with the complexity of the framework already.
yup. Which is why it would be good to make it simpler, which I believe
these changes will do, as I tried to point out.
> Patterns within
> patterns... It is not whether there are patterns or not - it is
> the fact that you have patterns of patterns, and you must somehow
> grasp them all.
"patterns of patterns" ... that's a good way to describe it =)
I got started with avalon by writing a nifty horror called XCommander.
I'm quite sure I didn't understand all of those patterns then, though.
We should separate what you need to grasp to work with avalon, and what
you need to know to work with it perfectly. Just like there's many
levels of java programming skill (you don't need to know clasloaders to
write an applet that does tic tac toe).
> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not committed
> to API stability, (2) just about when we've finally learned to use
> the framework (given how complex it is that may be a while), the next
> change will come along, (3) the cost of maintenance and keeping up
> with that will kill us. Let's roll our own framework."
yup. The thing to do is to change this perception so that it is clear
that (1) is not true, that the changes in (2) will make using the
framework both easier and simpler in the end, and to be very sure that
(3) will also not happen (ie backwards compatibility in a realistic
way).
> If it is more complicated or not does not matter - what matters is
> what it is *percieved* as.
yup.
Another thought: having users on a development list means we will have
more perceptions like this. Having a user list would remove some of
these concerns.
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: den 12 juni 2002 17:15
> To: 'Avalon Developers List'
> Subject: RE: [Summary] Avalon 5 ComponentManager interface
>
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Leo Simons [mailto:leosimons@apache.org]
> > >
> > > > Leo Sutic wrote:
> > > > > Carsten,
> > > > >
> > > > > you are right - everything gets a little bit more complicated.
> > > > >
> > > > Yes, and this is the thing that worries me - I know a lot of
> people
> > > > saying "Avalon is too complicated" and this makes it
> even a little
> > > > bit more complicated,
> > >
> > > hmm. Is it more complicated?
> >
> > As Vadim said in a comparison of Cocoon and Struts: Cocoon
> developers
> > come from the "pattern hell" school of thought. (That was a point
> > against Cocoon, if anyone missed it.)
>
> It was not me! :)
It was Konstantin, right?
But it was well put, anyway.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > > Leo Sutic wrote:
> > > > Carsten,
> > > >
> > > > you are right - everything gets a little bit more complicated.
> > > >
> > > Yes, and this is the thing that worries me - I know a lot of
people
> > > saying "Avalon is too complicated" and this makes it even a
> > > little bit
> > > more complicated,
> >
> > hmm. Is it more complicated?
>
> As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> come from the "pattern hell" school of thought. (That was a point
> against Cocoon, if anyone missed it.)
It was not me! :)
> Worth thinking about, as I have seen some people here accusing
> Cocoon of not following patterns cleanly enough.
>
> As a matter of fact, I think we scare the shit out of most people
> with the complexity of the framework already. Patterns within
> patterns... It is not whether there are patterns or not - it is
> the fact that you have patterns of patterns, and you must somehow
> grasp them all.
>
> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not
committed
> to API stability, (2) just about when we've finally learned to use
> the framework (given how complex it is that may be a while), the next
My current client isn't even there yet :)
> change will come along,
> (3) the cost of maintenance and keeping up
> with that will kill us. Let's roll our own framework."
>
> If it is more complicated or not does not matter - what matters is
> what it is *percieved* as.
>
> For all its faults, A4 is *easy* to *use*. (Although I confess I never
> ever understood the RoleManager.)
Automatic pooling and transparency of component implementation to client
is two great features I like most in A4.
Vadim
> /LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > > Leo Sutic wrote:
> > > > Carsten,
> > > >
> > > > you are right - everything gets a little bit more complicated.
> > > >
> > > Yes, and this is the thing that worries me - I know a lot
> of people
> > > saying "Avalon is too complicated" and this makes it even a
> > little bit
> > > more complicated,
> >
> > hmm. Is it more complicated?
>
> As Vadim said in a comparison of Cocoon and Struts: Cocoon
> developers come from the "pattern hell" school of thought.
> (That was a point against Cocoon, if anyone missed it.)
>
> Worth thinking about, as I have seen some people here
> accusing Cocoon of not following patterns cleanly enough.
In Cocoon, there is a mixture of a number of styles and patterns,
etc. It does not necessarily translate to all Avalon applications.
Cocoon has a lot of work to do to simplify the component model.
> As a matter of fact, I think we scare the shit out of most
> people with the complexity of the framework already. Patterns within
> patterns... It is not whether there are patterns or not - it is
> the fact that you have patterns of patterns, and you must
> somehow grasp them all.
The CORE framework only specifies a minimalist set of patterns.
* All components are managed in containers
* Those containers are responsible for the lifecycle and lifestyle
of the components.
* The ComponentManager (should it be ComponentDirectory?) is used
by a client to gain access to other components.
We also have semantics regarding Avalon primitives like Configuration/
Parameters/Context.
The thing that is most confusing about Avalon is that the containers
do things differently--and we need to unify the approach. This is
a _simplification_, not anything more complex. Currently the way
we represent meta-data is all over the place. Fortress/ECM use a
RoleManager, Phoenix uses component info (.xinfo) files, etc.
That is because we have not yet specified anything more to the container
contract than the three bullets above.
Not supporting explicitly pooled components is a _simplification_,
not anything more complex. No other component framework I know of
places the concern of releasing pooled resources on the client, why
should we be any different.
What we need to do is provide alternatives to what the previous
generation of avalon users were able to do, and reasons or tradeoffs
for each approach.
> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not
> committed to API stability, (2) just about when we've finally
> learned to use the framework (given how complex it is that
> may be a while), the next
> change will come along, (3) the cost of maintenance and keeping up
> with that will kill us. Let's roll our own framework."
A large percentage of the changes can be worked around with a
compatibility layer. By including an Avalon 4 compatibility
jar, client projects can upgrade at their own pace--as they explore
which approach to pooled components they prefer.
> If it is more complicated or not does not matter - what
> matters is what it is *percieved* as.
A design goal of A5 should be to make it so that the component
developer doesn't really care if the component is pooled, created
fresh every time, has one instance per thread, or is threadsafe.
We should encourage them to write threadsafe code, but we do want
to simplify things, and make it look simpler--addressing your
perception problem.
So far the thing I don't like about the XXXXManager solution is
that it places the responsibility of pooling semantics on the
XXXXManager developer. The usage of the XXXXManager is not really
an issue as it is easier to use than
lookup(ROLE).select(hint).release().
I would prefer to make it so that it doesn't really matter if
something is pooled or not. However we do need to work out how
to hide it from the user in the best way.
>
> For all its faults, A4 is *easy* to *use*. (Although I
> confess I never ever understood the RoleManager.)
Leo, the RoleManager is not a Framework thing--it is used in both
ECM and Fortress.
It is their tool to map convenient shorthand names to your components.
In other words it is only meant to be a way for the container to
interpret a user friendly config file without hardcoding names in the
container.
For example, which is easier for a *user* to understand?
<component role="org.apache.excalibur.sourceresolve.SourceResolver"
class="org.apache.excalibur.sourceresolve.SourceResolverImpl"
handler="org.apache.excalibur.fortress.handlers.ThreadsafeHandler">
<my-config>My configuration element</my-config>
</component>
or
<source-resolver>
<my-config>My configuration element</my-config>
</source-resolver>
The role, class, handler information is container information--not user
information, and they take up a lot of space. By putting it in a
RoleManager,
the container can read "source-resolver" and know that it means the
role,class,handler combination above.
The configuration file becomes cleaner, while still general purpose.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > Leo Sutic wrote:
> > > Carsten,
> > >
> > > you are right - everything gets a little bit more complicated.
> > >
> > Yes, and this is the thing that worries me - I know a lot of people
> > saying "Avalon is too complicated" and this makes it even a
> little bit
> > more complicated,
>
> hmm. Is it more complicated?
As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
come from the "pattern hell" school of thought. (That was a point
against Cocoon, if anyone missed it.)
Worth thinking about, as I have seen some people here accusing
Cocoon of not following patterns cleanly enough.
As a matter of fact, I think we scare the shit out of most people
with the complexity of the framework already. Patterns within
patterns... It is not whether there are patterns or not - it is
the fact that you have patterns of patterns, and you must somehow
grasp them all.
So I completely understand Carsten. We will lose users. I see
before me someone saying "F*** it. (1) They are obviously not committed
to API stability, (2) just about when we've finally learned to use
the framework (given how complex it is that may be a while), the next
change will come along, (3) the cost of maintenance and keeping up
with that will kill us. Let's roll our own framework."
If it is more complicated or not does not matter - what matters is
what it is *percieved* as.
For all its faults, A4 is *easy* to *use*. (Although I confess I never
ever understood the RoleManager.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> Leo Sutic wrote:
> > Carsten,
> >
> > you are right - everything gets a little bit more complicated.
> >
> Yes, and this is the thing that worries me - I know a lot of people
> saying "Avalon is too complicated" and this makes it even a little
> bit more complicated,
hmm. Is it more complicated?
In practical terms, you currently do
compose( ComponentManager cm ) throws ComponentException
{
m_cm = cm;
m_comp = (BlaComp) m_cm.lookup( BlaComp.ROLE );
}
doStuff()
{
m_comp.doABitOfStuff();
}
dispose()
{
m_cm.release(m_comp);
}
which becomes:
compose( ComponentManager cm ) throws ComponentException
{
m_comp = (BlaComp) m_cm.lookup( BlaComp.ROLE );
}
doStuff()
{
m_comp.doABitOfStuff();
}
if your component is threadsafe. If it is not, and you wish to use it in
a multi-threaded environment:
compose( ComponentManager cm ) throws ComponentException
{
m_factory = (Factory) m_cm.lookup( BlaComp.ROLE + "/factory" );
// or something like that
}
doStuff()
{
m_comp = (BlaComp)m_factory.getInstance();
m_comp.doABitOfStuff();
m_comp.release();
}
> And as a final argument against this is upgrading from 4.x to 5.0
> which not only requires recompiling, but also recoding (ok, this
> is acceptable if there are only a few cases) but even using a
> different pattern.
avalon framework is all about patterns. An upgrade to avalon framework
is either a bugfix (minor revision), added functionality (major
revision, perhaps one day for SEDA-like stuff) or a pattern upgrade
(major version change).
There is no way to improve patterns without recoding (though it might be
possible to write tools that automate most of the recoding).
cheers,
- LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> Hmm,I really hope you are right.
>
> But if you look at the history of Avalon, the dramatic changes from
> (was it 2.x or) 3.x to 4.0 which was really a nightmare for real users
> of Avalon and now again (not so) dramatic changes from 4.x to 5.0,
> I guess many people will fear that there will also be dramatic changes
> in the future from 5.x to 6.0 and so on.
> So why should I use such a rapid moving target? How can I develop tools
> for it if my tools are out of date with the next release? And so on.
> This might happen or might not, who knows? But I know that this has
> happened in the past.
I think you should take into account avalon was "alpha" until 4.0, and
large parts of it still are (cornerstone, phoenix, apps). That status is
intended as a clear message to users "there will be dramatic changes
ahead". This is not the case for avalon framework.
I anticipate an avalon framework 4.2 (4.1 has no issues, so I don't
think there'll be more releases of that one) with some new features
(like interfaces defining metainfo), maybe a 4.3, then a 4.5 (with realy
new stuff like a SEDA implementation), all of which will be binary
backwards compatible.
Whether avalon framework 5 will be fully binary backwards compatible or
not has not been decided on yet, but I think it will be, even if it will
be through a "compatibility mode". Still, it is quite a bit off in the
future.
All this to assure that the current avalon framework 4.x is not a rapid
moving target. You might further find
http://www.mail-archive.com/avalon-phoenix-dev%40jakarta.apache.org/msg00390.html
to be of interest.
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> Actually I have quite the opposite view. I belive that what is
> happending at the moment is equivilent to ironing out the wrinkes on an
> excellant tapestry. When those wrinkles dissaper you will see more and
> more value as tools converge toward a common model, extensions to the
> framework become more and more unified, small inconsistencies in the
> abstractions between different layers dissapear. But the value is not
> having something the is perfect - no - the value is having something
> this is really consistent in implementation and abstraction - and that's
> funcamentally important if your automating development or runtime
> processes - and that's the magic that deliver simplicity.
>
Hmm,I really hope you are right.
But if you look at the history of Avalon, the dramatic changes from
(was it 2.x or) 3.x to 4.0 which was really a nightmare for real users
of Avalon and now again (not so) dramatic changes from 4.x to 5.0,
I guess many people will fear that there will also be dramatic changes
in the future from 5.x to 6.0 and so on.
So why should I use such a rapid moving target? How can I develop tools
for it if my tools are out of date with the next release? And so on.
This might happen or might not, who knows? But I know that this has
happened in the past.
And for a good framework we not only need very good concepts but also
a wide audience and acceptance.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Carsten Ziegeler wrote:
>Leo Sutic wrote:
>
>
>>Carsten,
>>
>>you are right - everything gets a little bit more complicated.
>>
>>
>>
>Yes, and this is the thing that worries me - I know a lot of people
>saying "Avalon is too complicated" and this makes it even a little
>bit more complicated,
>
Actually I have quite the opposite view. I belive that what is
happending at the moment is equivilent to ironing out the wrinkes on an
excellant tapestry. When those wrinkles dissaper you will see more and
more value as tools converge toward a common model, extensions to the
framework become more and more unified, small inconsistencies in the
abstractions between different layers dissapear. But the value is not
having something the is perfect - no - the value is having something
this is really consistent in implementation and abstraction - and that's
funcamentally important if your automating development or runtime
processes - and that's the magic that deliver simplicity.
Frankly, I have to confess - I'm really excited about A5.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > > Will it be possible to deploy A4 component in an A5
> > environment wihout
> > > rewriting a single character of code?
> > >
> > in the CM case, that means:
> >
> > - we cannot change the return value of CM.lookup() to Object
> > - we cannot remove CM.release()
>
> No, that means we provide a compatibility jar like Xalan did
> for a long time for Xalan 1 compatibility.
of course. We can have
org.apache.avalon.framework.component.ComponentManager
(A4 compatibility jar, with "Component lookup( Object )"
and "release()" methods; marked as deprecated)
and an
org.apache.XXXXXXXXX.component.ComponentManager
(A5, with "Object lookup( Object )" and no
"release()")
I ment:
- we should not change the return value of
o.a.a.f.component.ComponentManager.lookup() to Object
- we should not remove
o.a.a.f.component.ComponentManager.release()
> > this means we will have an avalon 5 container that will have
> > to determine whether it deals with an A4 or A5 component, and
> > choose which CM to use based on that.
> >
> > This is possible only if we add some meta-information for
> > components. So while it means we will not have to rewrite
> > code, we might have to rewrite some meta-information.
>
> Meta-info is easy to rewrite. Just like Peter did for the
> Avalon 3 to Avalon 4 migration, we should also provide a
> script to change the imports and change Component to Object.
...and to remove any call to release() on the CM...
> That way there is very little hand coding that has to occur
> for migration of legacy components.
yup. I agree. It will still mean code changes to migrate, or a
compatibility mode... =)
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > So, are we all committed to making the upgrade gradual?
>
> yes. And it is way off in the future. Thing is, we can start
> mentioning the changes in the next 4.x release, but only if
> we know what they will be, which is why it is good to lay all
> this on the table now.
>
> > Will it be possible to deploy A4 component in an A5
> environment wihout
> > rewriting a single character of code?
> >
> > I think it must be.
>
> in the CM case, that means:
>
> - we cannot change the return value of CM.lookup() to Object
> - we cannot remove CM.release()
No, that means we provide a compatibility jar like Xalan did
for a long time for Xalan 1 compatibility.
> this means we will have an avalon 5 container that will have
> to determine whether it deals with an A4 or A5 component, and
> choose which CM to use based on that.
>
> This is possible only if we add some meta-information for
> components. So while it means we will not have to rewrite
> code, we might have to rewrite some meta-information.
Meta-info is easy to rewrite. Just like Peter did for the
Avalon 3 to Avalon 4 migration, we should also provide a
script to change the imports and change Component to Object.
That way there is very little hand coding that has to occur
for migration of legacy components.
>
> Also, based on the requirments Berin listed for avalon 5, we
> will need to use a different namespace (which is not a bad thing).
>
> - Leo Simons
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@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: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> So, are we all committed to making the upgrade gradual?
yes. And it is way off in the future. Thing is, we can start mentioning
the changes in the next 4.x release, but only if we know what they will
be, which is why it is good to lay all this on the table now.
> Will it be possible to deploy A4 component in an A5 environment
> wihout rewriting a single character of code?
>
> I think it must be.
in the CM case, that means:
- we cannot change the return value of CM.lookup() to Object
- we cannot remove CM.release()
this means we will have an avalon 5 container that will have to
determine whether it deals with an A4 or A5 component, and choose which
CM to use based on that.
This is possible only if we add some meta-information for components. So
while it means we will not have to rewrite code, we might have to
rewrite some meta-information.
Also, based on the requirments Berin listed for avalon 5, we will need
to use a different namespace (which is not a bad thing).
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> Leo Sutic wrote:
> > Carsten,
> >
> > you are right - everything gets a little bit more complicated.
> >
> Yes, and this is the thing that worries me - I know a lot of
> people saying "Avalon is too complicated" and this makes it
> even a little bit more complicated,
Yes. We will lose users in droves. I know.
I still consider the final summary to be the best compromise
between the different standpoints. (I.e. I got the stuff that
I need in order for me to stay with Avalon.)
> And as a final argument against this is upgrading from 4.x to
> 5.0 which not only requires recompiling, but also recoding
> (ok, this is acceptable if there are only a few cases) but
> even using a different pattern.
Oh, you'll get a rewrite. However, before 5.0 is rolled out,
backward compatibility classes will exist.
I do think we still at least somewhat believe that
"common framework" (http://jakarta.apache.org/avalon) means
some kind of API stability.
So, are we all committed to making the upgrade gradual?
Will it be possible to deploy A4 component in an A5 environment
wihout rewriting a single character of code?
I think it must be.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
> Carsten,
>
> you are right - everything gets a little bit more complicated.
>
Yes, and this is the thing that worries me - I know a lot of people
saying "Avalon is too complicated" and this makes it even a little
bit more complicated,
> But you can easily simplify it with a "golden hammer" solution.
> As my example shows, just add one attribute to each component
> declaration, and reshuffle your code a little teensy weensy bit,
> and you will have the same usage pattern over and over again.
> Just like now. There won't be 10000 usage patterns.
>
And as a final argument against this is upgrading from 4.x to 5.0
which not only requires recompiling, but also recoding (ok, this
is acceptable if there are only a few cases) but even using a
different pattern.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: den 12 juni 2002 15:18
> To: Avalon Developers List
> Subject: RE: [Summary] Avalon 5 ComponentManager interface
>
>
> Leo Sutic wrote:
> >
> > I agree completely.
> >
> > In my summary, I define Type 1 and Type 2,3 components.
> >
> > The Type 1 components are *always* thread safe. Always, always,
> > always. You *never* *ever* get a factory.
> >
> > Types 2 and 3 may or may not be threadsafe -> you *always* get a
> > factory. If the impl is threadsafe you get a factory anyway!
> >
> Ah, thanks for clarifying this - I think now I got it!
>
> > Basically, the presence/absence of a factory is defined by the
> > component interface. So if you code against the interface, you will
> > *always* get it right. Just like now. The only difference
> is that you
> > will lookup() the factories in compose() and then use them
> instead of
> > going to the ComponentManager.
> >
> Ok, I understand this issue - but - sorry - I don't see the
> advantage. In my opinion it gets more complicated as I first
> have to be aware of this distinction and on the other hand
> the configuration gets more complicated.
Carsten,
you are right - everything gets a little bit more complicated.
But you can easily simplify it with a "golden hammer" solution.
As my example shows, just add one attribute to each component
declaration, and reshuffle your code a little teensy weensy bit,
and you will have the same usage pattern over and over again.
Just like now. There won't be 10000 usage patterns.
I agree - I do not consider this optimal for my usage, but
I think it is the best compromise.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
>
> I agree completely.
>
> In my summary, I define Type 1 and Type 2,3 components.
>
> The Type 1 components are *always* thread safe. Always, always,
> always. You *never* *ever* get a factory.
>
> Types 2 and 3 may or may not be threadsafe -> you *always* get
> a factory. If the impl is threadsafe you get a factory anyway!
>
Ah, thanks for clarifying this - I think now I got it!
> Basically, the presence/absence of a factory is defined by the
> component interface. So if you code against the interface,
> you will *always* get it right. Just like now. The only difference is
> that you will lookup() the factories in compose() and then use them
> instead of going to the ComponentManager.
>
Ok, I understand this issue - but - sorry - I don't see the advantage.
In my opinion it gets more complicated as I first have to be aware
of this distinction and on the other hand the configuration gets more
complicated.
But I hope (fear?) that you all have discussed this over the last days.
Thanks,
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> Leo Sutic wrote:
>
> Yes, this should work, but I don't see the real advantage of
> it.
> Now, a component framework should make working with
> components very easy. As a client (or Composer) I personally
> don't want to care about ThreadSafe or not (that is in my
> eyes one of the big advantages of the current 4.x
> implementation, although there are some other problems...).
> Now, if I want to lookup a component, I have to know if it is
> ThreadSafe or not. If it is ThreadSafe I directly get the
> component on lookup - if not, I get a "factory" and need a
> second method call on this factory to get the real component.
>
> And I believe that the client a) should not care about this
> implementation detail and b) in some cases even might not
> know about it.
I agree completely.
In my summary, I define Type 1 and Type 2,3 components.
The Type 1 components are *always* thread safe. Always, always,
always. You *never* *ever* get a factory.
Types 2 and 3 may or may not be threadsafe -> you *always* get
a factory. If the impl is threadsafe you get a factory anyway!
Basically, the presence/absence of a factory is defined by the
component interface. So if you code against the interface,
you will *always* get it right. Just like now. The only difference is
that you will lookup() the factories in compose() and then use them
instead of going to the ComponentManager.
The only restriction is that if you need a pooled implementation of
a type 1 interface, you need to provide your own pool.
I predict that I'll stick to types 2 and 3, as I need to be able to
swap threadsafe/pooled components in and out. I predict Stephen
and Peter will stick to type 1, as they prefer to deal with pooling
in other ways.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
> >
> > Would work, but if that's the case, I have to implement a
> > "factory", the parser itself (including the "factory"
> > interface, the parser interface) etc. and I don't see the
> > great advantage in using a component framework anymore as I
> > code most part myself.
> >
> > Am I wrong?
>
> Carsten,
>
> you got it right. Those are exactly the implications of the
> proposal.
>
> Now for the good parts: The factory can be generic.
> So I code up a PooledFactory that takes your component class
> as a parameter, and bam there we go.
>
Thanks for your quick answer, Leo!
This sounds good, but... (more below)
> The only change is that you'll have to grab the factories
> out of the ComponentManager in the compose() method:
>
> <component role="org.ziegeler.CarstensComponent"
> class="Avalon4Factory"
> avalon-4-class="org.ziegeler.CarstensA4Component"
> pool-min="2"
> pool-max="4"/>
>
> ...
>
> public class CarstensComposer {
>
> A4Factory carstenFactory;
>
> public void compose (ComponentManager manager) {
> carstenFactory = (A4Factory) manager.lookup
> (org.ziegeler.CarstensComponent.ROLE);
> }
>
> public void doStuff () {
> CarstensComponent comp = (CarstensComponent)
> carstenFactory.getInstance ();
> try {
> comp.doStuff ();
> } finally {
> carstenFactory.release (comp);
> }
> }
> }
>
> Look at the configuration snippet, and replace "class" with
> "handler-class" and "avalon-4-class" with "class" and you get
> the idea.
>
> ..or am I trying to do the impossible here?
Yes, this should work, but I don't see the real advantage of it.
Now, a component framework should make working with components
very easy. As a client (or Composer) I personally don't want to
care about ThreadSafe or not (that is in my eyes one of the
big advantages of the current 4.x implementation, although there
are some other problems...).
Now, if I want to lookup a component, I have to know if it is
ThreadSafe or not. If it is ThreadSafe I directly get the component
on lookup - if not, I get a "factory" and need a second method call
on this factory to get the real component.
And I believe that the client a) should not care about this implementation
detail and b) in some cases even might not know about it.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> Would work, but if that's the case, I have to implement a
> "factory", the parser itself (including the "factory"
> interface, the parser interface) etc. and I don't see the
> great advantage in using a component framework anymore as I
> code most part myself.
>
> Am I wrong?
Carsten,
you got it right. Those are exactly the implications of the
proposal.
Now for the good parts: The factory can be generic.
So I code up a PooledFactory that takes your component class
as a parameter, and bam there we go.
The only change is that you'll have to grab the factories
out of the ComponentManager in the compose() method:
<component role="org.ziegeler.CarstensComponent"
class="Avalon4Factory"
avalon-4-class="org.ziegeler.CarstensA4Component"
pool-min="2"
pool-max="4"/>
...
public class CarstensComposer {
A4Factory carstenFactory;
public void compose (ComponentManager manager) {
carstenFactory = (A4Factory) manager.lookup
(org.ziegeler.CarstensComponent.ROLE);
}
public void doStuff () {
CarstensComponent comp = (CarstensComponent)
carstenFactory.getInstance ();
try {
comp.doStuff ();
} finally {
carstenFactory.release (comp);
}
}
}
Look at the configuration snippet, and replace "class" with
"handler-class" and "avalon-4-class" with "class" and you get
the idea.
..or am I trying to do the impossible here?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
> <snip/>
>
> We've agreed that all components returned from a CM are thread safe.
>
> <snip/>
Sorry for jumping in this late but I was away during the last 5 days
and tried to follow the thread of over 60 emails...but didn't directly
succeeded in finding why all components must be thread safe.
If I'm looking at the current implementation of many components available
in excalibur and in projects using avalon, there are many components NOT
thread safe and never will be. A simple one is a parser object.
Now, basically if I get a different parser object on each lookup there
are no real problems - also it's still not really thread safe.
But if I always get the same parser object, than this cannot work. So
in order to make it work I would return a "factory" like object from which
I can get a parser via getParser() or something which is than not
thread safe.
Would work, but if that's the case, I have to implement a "factory", the
parser itself (including the "factory" interface, the parser interface) etc.
and I don't see the great advantage in using a component framework anymore
as I code most part myself.
Am I wrong? If someone could point me to the mail, explaining how all
components returned from a CM can be thread safe, I would be very happy!
Thanks
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > Why not standardize on one approach? I.e., leave only
> > transformerManager.release (transformer) or
> > transformer.release(), and don't have zoo of different
> > methods doing the same?
>
> Because I did not think I could get that through the
> voting process. The current proposal is a best compromise.
I suggest we do one thing at a time (ie, agree to vote on this as a
separate issue).
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> <snip/>
>
> > public void doStuff () {
> > Transformer transformer = transformerManager.getTransformer
> ();
> > try {
> > } finally {
> > transformerManager.release (transformer);
> > // OR
> > transformer.release();
> > // OR
> > transformer.endDocument();
> > }
> > }
>
> Why not standardize on one approach? I.e., leave only
> transformerManager.release (transformer) or
> transformer.release(), and don't have zoo of different
> methods doing the same?
Because I did not think I could get that through the
voting process. The current proposal is a best compromise.
If you want to push for it, I'm with you, but I think we'll
deadlock.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
<snip/>
> public void doStuff () {
> Transformer transformer = transformerManager.getTransformer
();
> try {
> } finally {
> transformerManager.release (transformer);
> // OR
> transformer.release();
> // OR
> transformer.endDocument();
> }
> }
Why not standardize on one approach? I.e., leave only
transformerManager.release (transformer) or transformer.release(), and
don't have zoo of different methods doing the same?
> As seen above, for components whose interface makes them
thread-unsafe,
> there *must* be a method, either in the associated manager, or in the
> component itself, that, when called by the client, indicates that
> the client is finished using the component.
Especially if there is consensus that method must exist... Why not
standardize on method name?
<snip/>
Vadim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> but, understanding that, is it a policy to discourage the use of the
> ComponentManager outside of compose(), i.e. are the following bad:
no. In the current CM, there's a release() method which is not really
ment to be called inside compose() (though you can do that as well if
you want), but at a later stage.
I'd recommend getting your references as early as possible though (ie
during initialization) if at all possible.
In the new setup, without the release(), that will mean the CM could get
GCed earlier on. Maybe a container could call the GC after initializing
but before the system is "running", for example.
> or
>
> private TypeTwoInterface m_type2;
>
> public void begin()
> {
> m_type2 = (TypeTwoInterface) m_cm.lookup( "TypeTwoInterface" );
> m_type2.begin();
> }
>
> public void foo()
> {
> m_type2.bar()
> }
>
> public void end()
> {
> m_type2.end();
> m_type2 = null; // let the GC clean it up :)
> }
>
>
> why is it wrong for the composer you mention to not be threadsafe? and if
> it declares itself non-threadsafe (or fails to decleare itself
> threadsafe), how is it bad to use a non-threadsafe component over several
> methods (as in the second example above)?
Because there is no guarantee that the same component will not be called
by some other component between begin() and end().
While a container could possibly guarantee this by creating new
instances, that has to do with the contract between container and
component, and not with the contract between component and the
ComponentManager.
Note that a related topic is Berin's thoughts on sessions (also recent).
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
> > If we make the following assumptions:
> >
> > type 1 interface (no transaction): client may assume the component is
> > threadsafe
> >
> > type 2 or 2 interface (transaction involved): client may *not* assume
> > the component is threadsafe.
>
> Actually, even with my previous correction, my argument fails unless the
> second assumption is changed to allow the client to assume the component
> is threadsafe outside the transaction -- as this is getting less and less
> desirable, I think I might drop it, apologies for the wasted bandwidth :)
what I said here is wrong (and doesn't make complete sense)... my argument
did work (with the first correction) --- it seems that my postings are
starting to become a good approximation to thinking-out-loud.
When I wrote this I was a little confused by the following example - which
shows that the definition of transaction I was using was flawed (I'll try
to fix this in my next email)...
consider the interface:
interface Command
{
/** Contract: this method only gets called once */
public void execute();
}
which could be implemented as:
class CommandComponent implements Command // and lifecycle interfaces
{
private Type2Interface m_type2;
public void compose( ComponentManager cm )
{
m_type2 = (TypeTwoInterface) cm.lookup( "TypeTwoInterface" );
}
public void execute()
{
m_type2.begin();
m_type2.foo();
m_type2.bar();
m_type2.end();
}
}
My confusion came about because I was thinking of the Command interface as
being type 1. But it isn't, it is really type 2 with the execute() method
marking the begining *and* end of the transaction -- hence I need to
revise my definition of transaction... see next email...
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
> If we make the following assumptions:
>
> type 1 interface (no transaction): client may assume the component is
> threadsafe
>
> type 2 or 2 interface (transaction involved): client may *not* assume
> the component is threadsafe.
Actually, even with my previous correction, my argument fails unless the
second assumption is changed to allow the client to assume the component
is threadsafe outside the transaction -- as this is getting less and less
desirable, I think I might drop it, apologies for the wasted bandwidth :)
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
> now, if I'm writing a type 1 component then I may not lookup a type 2 or 3
> interface in compose/initalize and keep it throughout the lifetime of my
> type 1 component (since it would then fail to be threadsafe).
I mean: ... fail the no-resources-kept-by-the-component 'contract' of a
type 1 interface -- otherwise my argument is circular :)
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
On Wed, 12 Jun 2002, Leo Sutic wrote:
> > From: Robert Mouat [mailto:robert@mouat.net]
> >
> > but, understanding that, is it a policy to discourage the use
> > of the ComponentManager outside of compose(), i.e. are the
> > following bad:
>
> No. But anything coming out of a ComponentManager must be able to be
> used as I said - lookup() in compose and remains with the composer
> for its lifetime => threadsafe.
If we make the following assumptions:
type 1 interface (no transaction): client may assume the component is
threadsafe
type 2 or 2 interface (transaction involved): client may *not* assume
the component is threadsafe.
now, if I'm writing a type 1 component then I may not lookup a type 2 or 3
interface in compose/initalize and keep it throughout the lifetime of my
type 1 component (since it would then fail to be threadsafe).
however if I am writing a type 3 component the assumption that I be
threadsafe is gone, and hence I can lookup a type 2 or 3 interface in
compose/initialize and keep it throughout the lifetime.
[If I'm writing a type 2 component, I'd have to wait until the begining of
the transaction to lookup the type 2 or 3 interface].
IOW if MyComponent keeps a type 2 or 3 component over several methods then
MyComponent cannot be assumed to be threadsafe. And the assumption that
all lookups be threadsafe doesn't seem to give us anything.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Robert Mouat [mailto:robert@mouat.net]
>
> but, understanding that, is it a policy to discourage the use
> of the ComponentManager outside of compose(), i.e. are the
> following bad:
No. But anything coming out of a ComponentManager must be able to be
used as I said - lookup() in compose and remains with the composer
for its lifetime => threadsafe.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
Leo Sutic wrote:
> > From: Robert Mouat [mailto:robert@mouat.net]
> >
> > Leo Sutic wrote:
> >
> > > this is my understanding of the sort-of concensus we have arrived at.
> > > Some issues are still being debated, and I believe I have marked those
> > > as such.
> > <snip/>
> > > We've agreed on removing release() from the CM interface, and the rest
> > > of this sumary details how we get the same functionality without that
> > > method.
> > >
> > > We've agreed that all components returned from a CM are thread safe.
> >
> > I must have missed this (in my desire not to read any emails
> > containing "ROLE",hint vs. "ROLE/hint" :)... so I'm going to
> > ask: why must they be thread safe?
>
> Because they are looked up in compose() and then stays with the
> composer for the composer's lifetime. As there may be several threads
> in the composer accessing that component, it must be thread safe.
oops, looks like I confused threadsafe with singleton.
I think I understand this a little better now: interfaces that imply
a transaction also hint at non-threadsafety (i.e. prevent the
assumption of threadsafety)...
but, understanding that, is it a policy to discourage the use of the
ComponentManager outside of compose(), i.e. are the following bad:
private ComponentManager M_cm;
private TypeOneInterface m_type1;
public void compose( Component Manager cm )
{
m_cm = cm;
}
public void initialize()
{
m_type1 = (TypeOneInterface) m_cm.lookup( "TypeOneInterface" );
}
public void doStuff()
{
type2 = (TypeTwoInterface) m_cm.lookup( "TypeTwoInterface" );
type2.begin();
//...
type2.end();
}
or
private TypeTwoInterface m_type2;
public void begin()
{
m_type2 = (TypeTwoInterface) m_cm.lookup( "TypeTwoInterface" );
m_type2.begin();
}
public void foo()
{
m_type2.bar()
}
public void end()
{
m_type2.end();
m_type2 = null; // let the GC clean it up :)
}
why is it wrong for the composer you mention to not be threadsafe? and if
it declares itself non-threadsafe (or fails to decleare itself
threadsafe), how is it bad to use a non-threadsafe component over several
methods (as in the second example above)?
Robert.
P.S. apologies if this has been covered in a previous thread.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Robert Mouat [mailto:robert@mouat.net]
>
> Leo Sutic wrote:
>
> > this is my understanding of the sort-of concensus we have
> arrived at.
> > Some issues are still being debated, and I believe I have
> marked those
> > as such.
> <snip/>
> > We've agreed on removing release() from the CM interface,
> and the rest
> > of this sumary details how we get the same functionality
> without that
> > method.
> >
> > We've agreed that all components returned from a CM are thread safe.
>
> I must have missed this (in my desire not to read any emails
> containing "ROLE",hint vs. "ROLE/hint" :)... so I'm going to
> ask: why must they be thread safe?
Because they are looked up in compose() and then stays with the
composer for the composer's lifetime. As there may be several threads
in the composer accessing that component, it must be thread safe.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Summary] Avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
Leo Sutic wrote:
> this is my understanding of the sort-of concensus we have arrived at.
> Some issues are still being debated, and I believe I have marked those
> as such.
<snip/>
> We've agreed on removing release() from the CM interface, and the rest
> of this sumary details how we get the same functionality without
> that method.
>
> We've agreed that all components returned from a CM are thread safe.
I must have missed this (in my desire not to read any emails containing
"ROLE",hint vs. "ROLE/hint" :)... so I'm going to ask: why must they be
thread safe?
As I've said before it is possible for the container/CM/pool to use the
VM's GC to detect when a client has lost all references to a component.
This allows the component to be returned to a pool (recycled), or be
disposed automatically once the client loses all references to it.
If the component is only taking up memory this is not an issue since it is
exactly when the memory starts to run out that the GC will release
(recycle or dispose of) the component.
The problems that were being brought up dealt with the component holding
onto scarce resources (e.g. filehandles and database connections) which I
talked about in my last email. More...
> Borrowing from Robert Mouat's mail:
>
> transaction:
>
> this is the period during which a component can be expected to hold
> a [non-memory] resource. This depends a lot on the interface, and
> I'm going to divide these into 3 categories:
>
> 1. The interface defines no transaction. e.g. those that can be
> implemented in a thread-safe manner. e.g.
>
> interface DocumentStore
> {
> public Document getDocument( String ref );
> public void putDocument( String ref, Document doc );
> }
>
> 2. The interface has its own transaction delineators.
> e.g. open/close, or begin/end. These clearly define when the
> transaction begins and ends, and there is no reason to suspect that
> a component holds any resources after the close/end method is
> called. [Since I'm really only considerating the end of the
> transaction only the close/end method is needed]. An example of
> this would be a SAX Transformer with its startDocument/endDocument
> methods, or a non-component example might be a java.io.InputStream
> with its close method.
>
> 3. Finally there are interfaces which imply a transaction (i.e. that
> the implementation may need to hold resources), but do not have any
> methods delineating the transaction. The only example I can think
> of for this one is not a component but the java.util.Iterator, which
> has a next() method but no ending method.
>
> (end quote)
>
> ------------------
> TYPE 1:
>
> Components of type 1 are looked up directly:
>
> public class MyComposer implements Composable {
>
> private DocumentStore store = null;
>
> public void compose (ComponentManager manager) {
> store = (DocumentStore) manager.lookup (DocumentStore.ROLE);
> }
> }
>
> Components of type 1 are never released. A client keeps a reference
> to it for the duration of its lifetime.
>
> I believe we have concensus on this.
>
> ------------------
> TYPES 2 and 3:
>
> Components of type two and three are not looked up directly:
>
> public class MyComposer implements Composable {
>
> private TransformerManager transformerManager = null;
>
> public void compose (ComponentManager manager) {
> transformerManager = (TransformerManager) manager.lookup
> (TransformerManager.ROLE);
> }
>
> public void doStuff () {
> Transformer transformer = transformerManager.getTransformer ();
> try {
> } finally {
> transformerManager.release (transformer);
> // OR
> transformer.release();
> // OR
> transformer.endDocument();
> }
> }
> }
>
> As seen above, for components whose interface makes them thread-unsafe,
> there *must* be a method, either in the associated manager, or in the
> component itself, that, when called by the client, indicates that
> the client is finished using the component.
>
> I believe we have concensus on this.
>
> (end summary)
>
> --------------------------------------------
>
> Implications of Type 1 (my own thoughts, no concensus on this):
>
> + As there is no release() or equivalent, the implementation is
> restricted to only holding resources during method invokations.
>
> + All implementations must be thread safe.
as I said above I don't see why they must be thread safe.
> Implications of types 2 and 3 (my own thoughts, no concensus on this):
>
> + As there is a release() or equivalent, the implementation may
> hold resources during the entire transaction.
>
> + Implementations may be thread safe, but need not be.
>
> + For components of this type selected with a hint, we still
> get the ugly two-step lookup we have with ComponentSelectors.
>
> + A XXXXManager interface and a corresponding implementation is
> needed for each type 2 and 3 component == more code to write.
I disagree in the case of type 2 components...
As long as the component doesn't hold any resources outside the
transaction (e.g. before the close/end method on the interface returns the
component releases all filehandles and database connections), then there
should be no problem with the ComponentManager returning the component
directly from the lookup() method and the container/CM/ppol waiting for
the VM's GC too inform them that the client has lost all references to the
component.
Robert.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Summary] Avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
All,
this is my understanding of the sort-of concensus we have arrived at.
Some issues are still being debated, and I believe I have marked those
as such.
The ComponentManager interface:
interface ComponentManager {
/**
* Issues:
*
* - Should it throw Exceptions on failed lookup or return null?
*/
public Object lookup (String role);
/**
* Issues:
*
* - Should it throw Exceptions on failed lookup or return null?
* - Should it exist at all?
* - Should the hint be a String?
*/
public Object lookup (String role, Object hint);
}
We've agreed on removing release() from the CM interface, and the rest
of this sumary details how we get the same functionality without
that method.
We've agreed that all components returned from a CM are thread safe.
Borrowing from Robert Mouat's mail:
transaction:
this is the period during which a component can be expected to hold
a [non-memory] resource. This depends a lot on the interface, and
I'm going to divide these into 3 categories:
1. The interface defines no transaction. e.g. those that can be
implemented in a thread-safe manner. e.g.
interface DocumentStore
{
public Document getDocument( String ref );
public void putDocument( String ref, Document doc );
}
2. The interface has its own transaction delineators.
e.g. open/close, or begin/end. These clearly define when the
transaction begins and ends, and there is no reason to suspect that
a component holds any resources after the close/end method is
called. [Since I'm really only considerating the end of the
transaction only the close/end method is needed]. An example of
this would be a SAX Transformer with its startDocument/endDocument
methods, or a non-component example might be a java.io.InputStream
with its close method.
3. Finally there are interfaces which imply a transaction (i.e. that
the implementation may need to hold resources), but do not have any
methods delineating the transaction. The only example I can think
of for this one is not a component but the java.util.Iterator, which
has a next() method but no ending method.
(end quote)
------------------
TYPE 1:
Components of type 1 are looked up directly:
public class MyComposer implements Composable {
private DocumentStore store = null;
public void compose (ComponentManager manager) {
store = (DocumentStore) manager.lookup (DocumentStore.ROLE);
}
}
Components of type 1 are never released. A client keeps a reference
to it for the duration of its lifetime.
I believe we have concensus on this.
------------------
TYPES 2 and 3:
Components of type two and three are not looked up directly:
public class MyComposer implements Composable {
private TransformerManager transformerManager = null;
public void compose (ComponentManager manager) {
transformerManager = (TransformerManager) manager.lookup
(TransformerManager.ROLE);
}
public void doStuff () {
Transformer transformer = transformerManager.getTransformer ();
try {
} finally {
transformerManager.release (transformer);
// OR
transformer.release();
// OR
transformer.endDocument();
}
}
}
As seen above, for components whose interface makes them thread-unsafe,
there *must* be a method, either in the associated manager, or in the
component itself, that, when called by the client, indicates that
the client is finished using the component.
I believe we have concensus on this.
(end summary)
--------------------------------------------
Implications of Type 1 (my own thoughts, no concensus on this):
+ As there is no release() or equivalent, the implementation is
restricted to only holding resources during method invokations.
+ All implementations must be thread safe.
Implications of types 2 and 3 (my own thoughts, no concensus on this):
+ As there is a release() or equivalent, the implementation may
hold resources during the entire transaction.
+ Implementations may be thread safe, but need not be.
+ For components of this type selected with a hint, we still
get the ugly two-step lookup we have with ComponentSelectors.
+ A XXXXManager interface and a corresponding implementation is
needed for each type 2 and 3 component == more code to write.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Leo Sutic wrote:
>
>>From: Peter Donald [mailto:peter@apache.org]
>>
>>On Tue, 11 Jun 2002 21:22, Leo Sutic wrote:
>>
>>>>From: Peter Donald [mailto:peter@apache.org]
>>>>
>>>>Same way as you deal with all resources. ie call close(),
>>>>release() etc.
>>>>
>>>So can I assume that every component, or every XXXXManager has a
>>>close() or release() method?
>>>
>>>Is this how you intend it to work:
>>>
>>...snip...
>>
>>Mostly except I would only define it for services that
>>allocate resources (or
>>potentially allocate resources). Theres a whole family of
>>services that don't
>>do that (ie they only act on what is given to them in method
>>call) and the
>>only state they use is setup at initialization time.
>>
>
>I'm fine with that.
>
Leo:
I currently playing around with the metainfo and metadata stuff in
Excalibur and have some interesting content emerging that is an
abstraction above any of the kernels or containers. The next step is to
figure out policy - i.e. how to express constraints/directive in the
metadata that would enable a kernel to do-the-right-thing. Given that
there appears to be some level of consensus emerging re. the
ComponentManager interface, could you do me a big favor and put
together of summary of the conclusion so that my picture of what is
needed/understood is nailed down as much as possible. I have some
initial thoughts and worries about managing this at the metalevel
(nothing insurmountable - more a question of making sure I've got a
clean picture of what's being proposed and validating this against
the metainfo structures).
Cheers, Steve.
>
>
>/LS
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Tue, 11 Jun 2002 21:22, Leo Sutic wrote:
> > > From: Peter Donald [mailto:peter@apache.org]
> > >
> > > Same way as you deal with all resources. ie call close(),
> > > release() etc.
> >
> > So can I assume that every component, or every XXXXManager has a
> > close() or release() method?
> >
> > Is this how you intend it to work:
> ...snip...
>
> Mostly except I would only define it for services that
> allocate resources (or
> potentially allocate resources). Theres a whole family of
> services that don't
> do that (ie they only act on what is given to them in method
> call) and the
> only state they use is setup at initialization time.
I'm fine with that.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Tue, 11 Jun 2002 21:22, Leo Sutic wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > Same way as you deal with all resources. ie call close(),
> > release() etc.
>
> So can I assume that every component, or every XXXXManager
> has a close() or release() method?
>
> Is this how you intend it to work:
...snip...
Mostly except I would only define it for services that allocate resources (or
potentially allocate resources). Theres a whole family of services that don't
do that (ie they only act on what is given to them in method call) and the
only state they use is setup at initialization time.
I tend to do pooling internal to components if at all and let them do all the
work inside as that way implementation is completely up to component rather
than component + pooling mechanisms.
--
Cheers,
Peter Donald
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Royal [mailto:proyal@apache.org]
>
> On Tuesday 11 June 2002 07:22 am, Leo Sutic wrote:
> > Basically, the contract is:
> >
> > "Every pair of component C and its associated CManager interfaces
> > must define a method that, when called by the client, indicates
> > that the client is finished using the component C. The method
> > may be in the CManager interface - for example,
> > CManager.release (C c) - or in the C interface - for example,
> > C.close (). Note that this contract applies to component
> > *interfaces*.
> > even if the implementation does not require an end-of-transaction
> > signal from the client, the method must be specified so
> > implementations
> > that do require such a signal can recieve them."
> >
> > How about that?
>
> Yes, but not for all components. Only components that are
> "heavy / scarce" in
> some respect and need to be pooled. (JDBC Connection, Cocoon
> pipeline
> components..)
OK - I'm fine with that. If it is inherent in a component's interface
that it does not need to be released ever, then - no release() or
equivalent.
I just do not want to come across a situation where my implementation
of a component interface requires release() and the interface does
not have it. (Thus, the code using the component will never call it.)
For example:
public interface PetersComponent {
public final static String ROLE = "...";
public void doStuff ();
}
public class LeosImplementation implements PetersComponent {
public void doStuff () {
// ...
}
public void release () {
// Must be called, but how? PetersComponent does not specify it,
// so users of this interface never calls release() or any
equivalent.
}
}
But I'm fine with:
/**
* Proof that implementations of PetersComponentThatNeverNeedsRelease
* will never need a release() method
*
* ...
*
* Q.E.D.
*/
public interface PetersComponentThatNeverNeedsRelease {
public final static String ROLE = "...";
public void doStuff ();
}
public class LeosImplementation
implements PetersComponentThatNeverNeedsRelease {
public void doStuff () {
// ...
}
// No release() needed.
}
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 11 June 2002 07:22 am, Leo Sutic wrote:
> Basically, the contract is:
>
> "Every pair of component C and its associated CManager interfaces
> must define a method that, when called by the client, indicates
> that the client is finished using the component C. The method
> may be in the CManager interface - for example,
> CManager.release (C c) - or in the C interface - for example,
> C.close (). Note that this contract applies to component
> *interfaces*.
> even if the implementation does not require an end-of-transaction
> signal from the client, the method must be specified so
> implementations
> that do require such a signal can recieve them."
>
> How about that?
Yes, but not for all components. Only components that are "heavy / scarce" in
some respect and need to be pooled. (JDBC Connection, Cocoon pipeline
components..)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Leo Simons [mailto:leosimons@apache.org]
> Sent: den 11 juni 2002 18:05
> To: Avalon Developers List
> Subject: RE: [proposal] avalon 5 ComponentManager interface
>
>
> > > Same way as you deal with all resources. ie call close(),
> > > release() etc.
> >
> > So can I assume that every component, or every XXXXManager
> > has a close() or release() method?
>
> I'd not suggest that...if you want to isolate the client from
> determining whether the component has/needs the
> close()/release(), use a utility.
>
> > "Every pair of component C and its associated CManager interfaces
> > must define a method that, when called by the client, indicates
> > that the client is finished using the component C. The method
> > may be in the CManager interface - for example,
> > CManager.release (C c) - or in the C interface - for example,
> > C.close (). Note that this contract applies to component
> > *interfaces*.
> > even if the implementation does not require an end-of-transaction
> > signal from the client, the method must be specified so
> > implementations
> > that do require such a signal can recieve them."
> >
> > How about that?
>
> make that:
>
> A component must define a method with the following signature:
>
> public void release();
>
> or a component's manager (if it exists) must define a method
> with the following signature:
>
> public void release( Object );
>
> at the interface level, that, when called by a client,
> indicates that the client is finished using the component if
> it has any resources that require releasing.
I we removed the "if it has any resources that require releasing."
I'd be with you.
> You can even write a ReleaseUtil
I'd prefer all components to have one way of releasing them,
so you didn't have to check for specific implementation details
(requires release), but could just treat all components the same.
That is,
A component interface must define a method with the following
signature:
public void release();
or a component's manager (if it exists) must define a method
with the following signature:
public void release( Object );
Period.
Much easier to code for. I'm also fine with the release() method
being called close() in some components and endDocument() in some.
Just that there is one.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> > Same way as you deal with all resources. ie call close(),
> > release() etc.
>
> So can I assume that every component, or every XXXXManager
> has a close() or release() method?
I'd not suggest that...if you want to isolate the client from
determining whether the component has/needs the close()/release(), use a
utility.
> "Every pair of component C and its associated CManager interfaces
> must define a method that, when called by the client, indicates
> that the client is finished using the component C. The method
> may be in the CManager interface - for example,
> CManager.release (C c) - or in the C interface - for example,
> C.close (). Note that this contract applies to component
> *interfaces*.
> even if the implementation does not require an end-of-transaction
> signal from the client, the method must be specified so
> implementations
> that do require such a signal can recieve them."
>
> How about that?
make that:
A component must define a method with the following signature:
public void release();
or a component's manager (if it exists) must define a method with the
following signature:
public void release( Object );
at the interface level, that, when called by a client, indicates that
the client is finished using the component if it has any resources that
require releasing.
You can even write a ReleaseUtil that uses some minimal reflection to
determine whether the method exists and calls it if it does, then always
use that in all of your components (have this in C++ project of mine).
ReleaseUtil::release( component, manager )
if component has method "public void release()"
component.release()
return
if manager has method "public void release(Object)"
manager.release( component )
return
I would prefer though (cleaner, no reflection):
/**
* If an object implements this interface, it is the responsibility
* of anyone that uses it to call the release() method when it is done
* using it.
*/
interface RequiresRelease
{
public void release();
}
so you get
class ReleaseUtil
{
public static release( Object obj )
{
if( obj instanceof RequiresRelease )
((RequiresRelease)obj).release();
}
}
class SomeComponent
{
SomeManager m; // presumably a pool...
compose( ComponentManager cm ) throws ComponentException
{
m = cm.lookup( SomeManager.ROLE );
}
doWork()
{
try
{
SomeObject comp = m.getObject();
//bla
}
catch( Throwable t )
{
//logme
}
finally
{
ReleaseUtil.release( comp );
}
}
}
point is: release() is not made part of the lifecycle part of the
framework or any of those interfaces.
This should probably become a part of a generic pooling solution.
cjeers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Peter Donald [mailto:peter@apache.org]
> > >
> > > Same way as you deal with all resources. ie call close(),
> > > release() etc.
> >
> > So can I assume that every component, or every XXXXManager
> > has a close() or release() method?
>
> Leo, before you go crazy down this road, not every
> XXXXManager needs to work with pooled resources.
OK, if it is a property of the component interface that an
implementation can never, ever be pooled, then fine. No release()
or equivalent. But those would be fairly few.
What about the rest of my mail? Specifically, what about the
proposed contract and use case?
> Consider EJBs--which are the epitome of monolithic design in
> a component architecture. There is no explicit release for a
> component, yet the components are pooled. The container is
> in absolute control of the component.
By requiring all instances to be serializable so they can be
swapped in and out as needed. Do you wish to add that constraint
to Avalon components?
> The point is that it can be done, without an explicit release
> mechanism.
Well yes, but can you please:
1) Describe such a mechanism. Not just theorize about the possible
existence of it.
2) Explain how it allows me to use scarce resources (DB connections).
3) Works with component interfaces without a close() or endDocument()
or similar.
4) Explain how it allows me to switch from pooled to threadsafe
components without changing the way I interact with the
component.
5) Describe all constraints it puts on the component implementation.
Berin, so far you have not produced a single mechanism that does what
you claim is possible without serious constraints being put on the
component writer or user - serious enough to make Avalon utterly
unusable.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > Same way as you deal with all resources. ie call close(),
> > release() etc.
>
> So can I assume that every component, or every XXXXManager
> has a close() or release() method?
Leo, before you go crazy down this road, not every XXXXManager
needs to work with pooled resources. If that is one possibility,
then yes, it needs to provide an interface for for pooling. However,
when you develop a component instance, or a processing artifact,
you work within the design constraints placed on you.
Consider EJBs--which are the epitome of monolithic design in a
component architecture. There is no explicit release for a component,
yet the components are pooled. The container is in absolute control
of the component.
The point is that it can be done, without an explicit release
mechanism.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> Same way as you deal with all resources. ie call close(),
> release() etc.
So can I assume that every component, or every XXXXManager
has a close() or release() method?
Is this how you intend it to work:
/**
* The ConnectionManager does not define
* a release() method, as you call close()
* on the connection instead.
*/
interface ConnectionManager {
public static final String ROLE = "...";
Connection getConnection ();
}
interface Connection {
void doSomething ();
void close ();
}
/**
* The OtherManager *must* define a release() method,
* as the Other interface provides no way for the client to
* indicate that it is finished using the Other instance.
*/
interface OtherManager {
public static final String ROLE = "...";
Other getInstance ();
void release (Other other);
}
/**
* This interface does not specify any way for the client to
* indicate that the instance can be put back into a pool.
*/
interface Other {
/**
* May be called any number of times in a transaction.
*/
void doSomething();
}
class MyComposer implements Composable {
private ConnectionManager connectionManager;
private OtherManager otherManager;
public void compose(ComponentManager manager) {
connectionManager = (ConnectionManager) manager.lookup
(ConnectionManager.ROLE);
otherManager = (OtherManager) manager.lookup (OtherManager.ROLE);
}
public void doWork () {
Connection conn = null;
Other other = null;
try {
conn = connectionManager.getConnection ();
other = otherManager.getInstance ();
conn.doSomething ();
other.doSomething ();
} catch (Exception e) {
} finally {
if (conn != null) conn.close ();
otherManager.release (other);
}
}
}
Basically, the contract is:
"Every pair of component C and its associated CManager interfaces
must define a method that, when called by the client, indicates
that the client is finished using the component C. The method
may be in the CManager interface - for example,
CManager.release (C c) - or in the C interface - for example,
C.close (). Note that this contract applies to component
*interfaces*.
even if the implementation does not require an end-of-transaction
signal from the client, the method must be specified so
implementations
that do require such a signal can recieve them."
How about that?
> The Connector API aims to standardize heavy
> resource management in J2EE
> land and JDBC will implement it in the future (unless JDK1.4
> version does?)
> and most vendors will use that API.
And what does that have to do with this? The Connector API is about
connecting different systems, not about the presense of a way to
explicitly release resources. I do note, however, that many interfaces
specify a close() method or other way of releasing resources.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 08:45 AM 6/11/2002 +0200, you wrote:
>>>>2) removal of release()
>
>-1
>
>Still don't understand how I can deallocate a scarse resource as soon
>as possible :-/
>How the hell can I release a scarse resource right away?
Same way as you deal with all resources. ie call close(), release() etc.
The Connector API aims to standardize heavy resource management in J2EE
land and JDBC will implement it in the future (unless JDK1.4 version does?)
and most vendors will use that API.
For lower cost in memory objects then you release them or put them back in
the pool explicitly ala
interface GeneratorManager
{
get()
release()
}
>>>>3) replacement of Component with Object
>>>
>>>+1s
>
>+1
>
>Why did we use _Component_ in the first place?
Because I couldn't think of a good reason to kill it in the first place ;)
>that the container could recognize an Avalon Component ad treat it as such.
No. Thats why we had the Block/Service interfaces (in Phoenix). As a sort
of metainfo to identify objects but that ended up being a bad idea as we
had metainfo scattered across configuration files and implemenentation
classes. The motivation for Component was different.
>What was the need?
Mainly as it forces people to think about what constitutes a service and
what isn't. ie It clearly markes the difference between Component and
Object. In effect it did not really achieve that end. If you look at some
of the code I wrote I ended up having to do a lot of work arounds. Consider
the case where I have service X that is independent of Avalon. To use it I
ended up having to having to do
class ExtendedX extends A implements Component
{
}
or
interface XManager
{
X getX();
}
Neither which are elegant. You can still see the remanents of this sort of
thing in things like PhoenixPackageManager.
>>>>5) addition of an _optional_ lookup() method that supports hints, to
>>>>enable smooth migration from ComponentSelector usage
>>>
>>>-1s
>> From a pure framework perspective I'm totally in agreement with the
>> above (irrespective of the pain and suffering I'm enduring with respect
>> to the metainfo/metadata issues inflicted by an unmentionable
>> "Australia" personality). However, if we take into account ECM and the
>> interest in facilitating a smooth migration path, I see only two
>> alternative; either we provide a lookup( role, hint) in the framework
>> (which I dislike in terms of the curent form being dicusssed), or (b) an
>> extended CM is defintion at the excalibur level that provide a bridge
>> from ECM to the emerging container models.
>
>Now, this thing of /hints/ got me thinking.
>
>As I said previously, it seems that:
>
>Role: what
>Hint: how
>
>This means that if I ask for an XSLT processor, I can hint to use Saxon,
>but it can give me also Crimson.
>No problem for me, as long as it's XSLT spec compatible (ROLE).
This is very very similar to what Stephen is doing in Merlin wrt to
policies. ie Component A declares a dependency on Role P. If there is only
one P in the system then that P will be used - however if there is multiple
Ps in the system (namely x, y and z) then one of them will be selected
based on a heuristic that takes a policy (aka a hint).
The difference between Merlins model and the Cocoon model is that in Cocoon
the metainfo (ie hint) is stored in code while in Merlin it is stored in
descriptor (aka a .xinfo file).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 09:52 AM 6/11/2002 +0200, you wrote:
>Seems like you're looking for a different ROLE, then:
>
>interface SSLConnectionManager extends ConnectionManager {};
>
>or is that too bulky?
Seems like a workaround for limitations in the framework.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>>>> Nicola Ken Barozzi wrote:
>>>>
>>>>> How can we make an Object be sure that it's being treated by an
>>>>> Avalon container?
>>>>
>>>>
>>>> we cannot (in a way expressed in java code). Is there a need?
>>>
>>>
>>> Definately, IMNSHO.
>>> I've seen many users start Avalon Components with new, and wait to see
>>> the Avalon interface methods called :-O
>>>
>>> If the component isn't created in a container, it woud be cool if it
>>> could barf.
>>>
>>> <attention mode="heretic">
>>> Component interface as a teg interface is useless and in some cases
>>> bad for reasons already expressed.
>>> But maybe we could make an abstrace SafeService that can act as a
>>> base class to extend to make a Service that can be created only by a
>>> container: private method, creator method and check of proper order
>>> of interface calling.
>>> </attention>
>>
>>
>> *eeek* - drop the capatilized Container and I'm with you.
>
>
> container (it's what I meant ;-)
>
> > A component is
>
>> described in terms of interfaces and lifecycle semantics that are
>> managed by an implementation. We tend to refer to the
>> imnplementation as a container because this makes sence in the
>> overall pattern of usage. What you really need to rugged testing in
>> the contents you make public to make sure that usage outside of a
>> managed context results in quick failure. This is also one of the
>> prime objectives of Merlin - a mechanisms to do exacly what your
>> user's want to do - just run the component.
>
>
> I want the object to complain if its lifecycle methods are called in
> the wrong order or not called before other things.
> Basically checking that it's being created by an external controller
> entity that is not simply new().
>
>
>>>>>>>> 5) addition of an _optional_ lookup() method that supports
>>>>>>>> hints, to
>>>>>>>> enable smooth migration from ComponentSelector usage
>>>>>>>
>>>>>>>
>>>>>>> -1s
>>>>>>
>>>>>>
>>>>>> From a pure framework perspective I'm totally in agreement with
>>>>>> the above (irrespective of the pain and suffering I'm enduring
>>>>>> with respect to the metainfo/metadata issues inflicted by an
>>>>>> unmentionable "Australia" personality). However, if we take into
>>>>>> account ECM and the interest in facilitating a smooth migration
>>>>>> path, I see only two alternative; either we provide a lookup(
>>>>>> role, hint) in the framework (which I dislike in terms of the
>>>>>> curent form being dicusssed), or (b) an extended CM is defintion
>>>>>> at the excalibur level that provide a bridge from ECM to the
>>>>>> emerging container models.
>>>>>
> >>>>
>
>>>>> Now, this thing of /hints/ got me thinking.
>>>>>
>>>>> As I said previously, it seems that:
>>>>>
>>>>> Role: what
>>>>> Hint: how
>>>>
>>>>
>>>> ...
>>>>
>>>>
>>>>> ROLE: what it should do
>>>>> CHARACTERIZATION: how it should do it
>>>>> PREFERRED ACTOR: hint about *who* should do it
>>>>
>>>>
>>>> nope.
>>>>
>>>> The role determines what part a component plays in your
>>>> application; it
>>>> is perfectly valid for the role to include information on the "how".
>>>>
>>>> Tight coupling of role to interface name is merely a convenience (it
>>>> allows us to get away with easy casts).
>>>
> >>
>
>>> I'm not so sure.
>>> What do the Connection and SSLConnection components do?
>>> Make a connection.
>>> They use the same interfaces.
>>>
>>> I should be able to say that I just need to make a connection or
>>> that I need to make a *certain* type of connection.
>>>
>>> If we say that SSLConnection is a role itself, it will not be given me.
>>>
>>> The fact is that sometimes I want the container to decide for me,
>>> sometimes I don't.
>>> When the container decides, I just specify a role.
>>> When I decide, I also specify a sub-role.
>>>
>>>>> Well, this shows that hints are really not needed.
>>>>
>>>>
>>>> yup. Except we have to take into account an already existing CS.
>>>
>>>
>>> That use a hint as a sub-role usually.
>>>
>>>>> The point is that we need a sub-role.
>>>>> An interface (Role), tells me what to do, but does not specify how
>>>>> it should be done.
>>>>> This is not something that can be forgotten, as in the SSL case.
>>>>>
>>>>> I would deprecate hints in favor of sub-roles (or call them in a
>>>>> better way, I'm no ace in names ;-)
>>>>
>>>>
>>>> strings are pretty free-form. It is easy to describe both a role "king
>>>> of all England" and a sub-role "mad" in a single string: "mad king of
>>>> all England".
>>>
>>>
>>> This is an implementation detail.
>>> Or you do Role,SubRole or "role/subrole".
>>> It's not a problem, but semantically there is a point in defining
>>> role and subrole.
>>>
>>
>> Role is simply a key that is unique within the scope of the CM/SM
>> that is supplied to a component. Any semantics beyond that imply
>> that your component has a private arrangement with its container in
>> that the semantics of the lookup interface are modified by the
>> introduction of dark-magic ... which means its not a portable component.
>
>
> Hmmm, I mean that simply using a unique key is not enough.
> In sentences, I want subjects (the container), verbs (the ROLE) and
> other stuff that specializes (sub-role).
>
> I need hierarchy, with the ability of stopping at a more generic level
> (do it!) or going in more detail (do it with SSL!).
>
No problem - you define a component with service interface that
understands these notions and you declare this as a dependecy of the
component that needs this level of selection functionality. The CM/SM
default implementations will provide it to you. Take a look at the
DefaultServiceManager and DefaultComponentManager code and you will see
that role argument is simply applied as a key in a table, and if not
found passed to the parent manager or an exception is thrown. I.e. no
magic - no interpritation of the role argument.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
>>> Nicola Ken Barozzi wrote:
>>>> How can we make an Object be sure that it's being treated by an
>>>> Avalon container?
>>>
>>> we cannot (in a way expressed in java code). Is there a need?
>>
>> Definately, IMNSHO.
>> I've seen many users start Avalon Components with new, and wait to see
>> the Avalon interface methods called :-O
>>
>> If the component isn't created in a container, it woud be cool if it
>> could barf.
>>
>> <attention mode="heretic">
>> Component interface as a teg interface is useless and in some cases
>> bad for reasons already expressed.
>> But maybe we could make an abstrace SafeService that can act as a base
>> class to extend to make a Service that can be created only by a
>> container: private method, creator method and check of proper order of
>> interface calling.
>> </attention>
>
> *eeek* - drop the capatilized Container and I'm with you.
container (it's what I meant ;-)
> A component is
> described in terms of interfaces and lifecycle semantics that are
> managed by an implementation. We tend to refer to the imnplementation
> as a container because this makes sence in the overall pattern of usage.
> What you really need to rugged testing in the contents you make public
> to make sure that usage outside of a managed context results in quick
> failure. This is also one of the prime objectives of Merlin - a
> mechanisms to do exacly what your user's want to do - just run the
> component.
I want the object to complain if its lifecycle methods are called in the
wrong order or not called before other things.
Basically checking that it's being created by an external controller
entity that is not simply new().
>>>>>>> 5) addition of an _optional_ lookup() method that supports hints, to
>>>>>>> enable smooth migration from ComponentSelector usage
>>>>>>
>>>>>> -1s
>>>>>
>>>>> From a pure framework perspective I'm totally in agreement with the
>>>>> above (irrespective of the pain and suffering I'm enduring with
>>>>> respect to the metainfo/metadata issues inflicted by an
>>>>> unmentionable "Australia" personality). However, if we take into
>>>>> account ECM and the interest in facilitating a smooth migration
>>>>> path, I see only two alternative; either we provide a lookup( role,
>>>>> hint) in the framework (which I dislike in terms of the curent form
>>>>> being dicusssed), or (b) an extended CM is defintion at the
>>>>> excalibur level that provide a bridge from ECM to the emerging
>>>>> container models.
>>>>
>>>> Now, this thing of /hints/ got me thinking.
>>>>
>>>> As I said previously, it seems that:
>>>>
>>>> Role: what
>>>> Hint: how
>>>
>>> ...
>>>
>>>
>>>> ROLE: what it should do
>>>> CHARACTERIZATION: how it should do it
>>>> PREFERRED ACTOR: hint about *who* should do it
>>>
>>> nope.
>>>
>>> The role determines what part a component plays in your application; it
>>> is perfectly valid for the role to include information on the "how".
>>>
>>> Tight coupling of role to interface name is merely a convenience (it
>>> allows us to get away with easy casts).
>>
>> I'm not so sure.
>> What do the Connection and SSLConnection components do?
>> Make a connection.
>> They use the same interfaces.
>>
>> I should be able to say that I just need to make a connection or that
>> I need to make a *certain* type of connection.
>>
>> If we say that SSLConnection is a role itself, it will not be given me.
>>
>> The fact is that sometimes I want the container to decide for me,
>> sometimes I don't.
>> When the container decides, I just specify a role.
>> When I decide, I also specify a sub-role.
>>
>>>> Well, this shows that hints are really not needed.
>>>
>>> yup. Except we have to take into account an already existing CS.
>>
>> That use a hint as a sub-role usually.
>>
>>>> The point is that we need a sub-role.
>>>> An interface (Role), tells me what to do, but does not specify how
>>>> it should be done.
>>>> This is not something that can be forgotten, as in the SSL case.
>>>>
>>>> I would deprecate hints in favor of sub-roles (or call them in a
>>>> better way, I'm no ace in names ;-)
>>>
>>> strings are pretty free-form. It is easy to describe both a role "king
>>> of all England" and a sub-role "mad" in a single string: "mad king of
>>> all England".
>>
>> This is an implementation detail.
>> Or you do Role,SubRole or "role/subrole".
>> It's not a problem, but semantically there is a point in defining role
>> and subrole.
>>
>
> Role is simply a key that is unique within the scope of the CM/SM that
> is supplied to a component. Any semantics beyond that imply that your
> component has a private arrangement with its container in that the
> semantics of the lookup interface are modified by the introduction of
> dark-magic ... which means its not a portable component.
Hmmm, I mean that simply using a unique key is not enough.
In sentences, I want subjects (the container), verbs (the ROLE) and
other stuff that specializes (sub-role).
I need hierarchy, with the ability of stopping at a more generic level
(do it!) or going in more detail (do it with SSL!).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
>>>>>> 3) replacement of Component with Object
>>>>>
>>>>>
>>>>> +1s
>>>>
>>>>
>>> +1
>>>
>>> Why did we use _Component_ in the first place?
>>
>>
>>
>> beautification.
>>
>>
>>> How can we make an Object be sure that it's being treated by an
>>> Avalon container?
>>
>>
>>
>> we cannot (in a way expressed in java code). Is there a need?
>
>
> Definately, IMNSHO.
> I've seen many users start Avalon Components with new, and wait to see
> the Avalon interface methods called :-O
>
> If the component isn't created in a container, it woud be cool if it
> could barf.
>
> <attention mode="heretic">
> Component interface as a teg interface is useless and in some cases
> bad for reasons already expressed.
> But maybe we could make an abstrace SafeService that can act as a base
> class to extend to make a Service that can be created only by a
> Container: private method, creator method and check of proper order of
> interface calling.
> </attention>
*eeek* - drop the capatilized Container and I'm with you. A component is
described in terms of interfaces and lifecycle semantics that are
managed by an implementation. We tend to refer to the imnplementation
as a container because this makes sence in the overall pattern of usage.
What you really need to rugged testing in the contents you make public
to make sure that usage outside of a managed context results in quick
failure. This is also one of the prime objectives of Merlin - a
mechanisms to do exacly what your user's want to do - just run the
component.
>
>>>>>> 5) addition of an _optional_ lookup() method that supports hints, to
>>>>>> enable smooth migration from ComponentSelector usage
>>>>>
>>>>>
>>>>> -1s
>>>>
>>>>
>>>> From a pure framework perspective I'm totally in agreement with the
>>>> above (irrespective of the pain and suffering I'm enduring with
>>>> respect to the metainfo/metadata issues inflicted by an
>>>> unmentionable "Australia" personality). However, if we take into
>>>> account ECM and the interest in facilitating a smooth migration
>>>> path, I see only two alternative; either we provide a lookup( role,
>>>> hint) in the framework (which I dislike in terms of the curent form
>>>> being dicusssed), or (b) an extended CM is defintion at the
>>>> excalibur level that provide a bridge from ECM to the emerging
>>>> container models.
>>>
>>>
>>> Now, this thing of /hints/ got me thinking.
>>>
>>> As I said previously, it seems that:
>>>
>>> Role: what
>>> Hint: how
>>
>>
>>
>> ...
>>
>>
>>> ROLE: what it should do
>>> CHARACTERIZATION: how it should do it
>>> PREFERRED ACTOR: hint about *who* should do it
>>
>>
>>
>> nope.
>>
>> The role determines what part a component plays in your application; it
>> is perfectly valid for the role to include information on the "how".
>>
>> Tight coupling of role to interface name is merely a convenience (it
>> allows us to get away with easy casts).
>
>
> I'm not so sure.
> What do the Connection and SSLConnection components do?
> Make a connection.
> They use the same interfaces.
>
> I should be able to say that I just need to make a connection or that
> I need to make a *certain* type of connection.
>
> If we say that SSLConnection is a role itself, it will not be given me.
>
> The fact is that sometimes I want the container to decide for me,
> sometimes I don't.
> When the container decides, I just specify a role.
> When I decide, I also specify a sub-role.
>
>>> Well, this shows that hints are really not needed.
>>
>>
>> yup. Except we have to take into account an already existing CS.
>
>
> That use a hint as a sub-role usually.
>
>>> The point is that we need a sub-role.
>>> An interface (Role), tells me what to do, but does not specify how
>>> it should be done.
>>> This is not something that can be forgotten, as in the SSL case.
>>>
>>> I would deprecate hints in favor of sub-roles (or call them in a
>>> better way, I'm no ace in names ;-)
>>
>>
>> strings are pretty free-form. It is easy to describe both a role "king
>> of all England" and a sub-role "mad" in a single string: "mad king of
>> all England".
>
>
> This is an implementation detail.
> Or you do Role,SubRole or "role/subrole".
> It's not a problem, but semantically there is a point in defining role
> and subrole.
>
Role is simply a key that is unique within the scope of the CM/SM that
is supplied to a component. Any semantics beyond that imply that your
component has a private arrangement with its container in that the
semantics of the lookup interface are modified by the introduction of
dark-magic ... which means its not a portable component.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Avalon hooking 'new'
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> > >How can we make an Object be sure that it's being treated by an Avalon
> > >container?
> >
> > we cannot (in a way expressed in java code). Is there a need?
>
> Definately, IMNSHO.
> I've seen many users start Avalon Components with new, and wait to see
> the Avalon interface methods called :-O
Yes, I do see the need for this as well.
Unfortunately, I don't see how Java could allow us to do this.
Anybody?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
jakarta-avalon-excalibur/util/src/java/org/apache/excalibur/util/Compone
ntStateValidator.java
We decided against an abstract base class.
/LS
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> And have:
>
> public void start()
> {
> if(initialized)throw new HeyManWhatAreYouDoingException();
> }
>
> public void initialize()
> {
> set initialized = true;
> }
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>><attention mode="heretic">
>>Component interface as a teg interface is useless and in some
>>cases bad
>>for reasons already expressed.
>>But maybe we could make an abstrace SafeService that can act
>>as a base
>>class to extend to make a Service that can be created only by a
>>Container: private method, creator method and check of proper
>>order of
>>interface calling.
>></attention>
>
> What you are proposing would *require* a minimal definition of
> a container in framework.
Nope, an abstract component that does checking.
And it's not a requirement, but a utility class that can help create
more errorproof components.
> A generic container cannot access
> private members of components unless it is a class enclosed
> in itself. Furthermore, a generic container cannot access
> protected members (including constructors) unless they are in
> the same package.
Of course, it needs a "creator method" (see above).
If we call it (wild try)
static Object createForContainer()
it would not make users just think that new() can make things work.
Also, it would have empty implementations of, let's say, Inititalizable
and Startable.
And have:
public void start()
{
if(initialized)throw new HeyManWhatAreYouDoingException();
}
public void initialize()
{
set initialized = true;
}
> It's just not feasible.
>
>
>>This is an implementation detail.
>>Or you do Role,SubRole or "role/subrole".
>>It's not a problem, but semantically there is a point in
>>defining role
>>and subrole.
>
> In essence what the CM as I have defined it would do. Just
> change the Object for String, and the name hint for subrole,
> and viola' you have what you are looking for.
Yes, I'm backing your calim that we need a secong role thing.
What I'm trying to show is that complying with hints was in fact
compulsory, not just a hint, hence the sub-role definition.
The connection-sslconnection example is exemplary.
Connection role says I want to talk.
PlainConnection
SSLConnection
are different sub-roles
MYPlainConnection1
YourPlainConnection2
MYSSLConnection
TomcatSSLConnection
are different implementations.
I would want just to talk, so I would need only one implementation, I
don't care which.
If I need an SSL connection, I would also ask for a subrole.
Discerning between concrete implementations, instead, has to be done by
the container.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> <attention mode="heretic">
> Component interface as a teg interface is useless and in some
> cases bad
> for reasons already expressed.
> But maybe we could make an abstrace SafeService that can act
> as a base
> class to extend to make a Service that can be created only by a
> Container: private method, creator method and check of proper
> order of
> interface calling.
> </attention>
What you are proposing would *require* a minimal definition of
a container in framework. A generic container cannot access
private members of components unless it is a class enclosed
in itself. Furthermore, a generic container cannot access
protected members (including constructors) unless they are in
the same package.
It's just not feasible.
> This is an implementation detail.
> Or you do Role,SubRole or "role/subrole".
> It's not a problem, but semantically there is a point in
> defining role
> and subrole.
In essence what the CM as I have defined it would do. Just
change the Object for String, and the name hint for subrole,
and viola' you have what you are looking for.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>>>>2) removal of release()
>>>>
>>-1
>>
>>Still don't understand how I can deallocate a scarse resource as soon as
>> possible :-/
>>How the hell can I release a scarse resource right away?
>>If processor hardware threads would never release() and use only a
>>timeout, what processors would we have? :-S
>>
>>I agree that release is *not* compulsory for pooling, but I don't see
>>replacements possible for handling of scarse resources.
>
>
> =) We remove pooling from the CM alltogether. That's "removal of
> release() from the CM (and putting the pool (with release() in the CM)".
Ah, now I get it. :-D
>>>>>3) replacement of Component with Object
>>>>
>>>>+1s
>>>
>>+1
>>
>>Why did we use _Component_ in the first place?
>
>
> beautification.
>
>
>>How can we make an Object be sure that it's being treated by an Avalon
>>container?
>
>
> we cannot (in a way expressed in java code). Is there a need?
Definately, IMNSHO.
I've seen many users start Avalon Components with new, and wait to see
the Avalon interface methods called :-O
If the component isn't created in a container, it woud be cool if it
could barf.
<attention mode="heretic">
Component interface as a teg interface is useless and in some cases bad
for reasons already expressed.
But maybe we could make an abstrace SafeService that can act as a base
class to extend to make a Service that can be created only by a
Container: private method, creator method and check of proper order of
interface calling.
</attention>
>>>>>4) replacement of ComponentException with exists() for lookup()
>>>>
>>-1
>>
>>Exception throwing is a contract with the caller, that states that the
>>caller is responsible for the Exception.
>
> I think it most likely that the exception will just be rethrown from
> compose(), so it ends up with the caller again.
Yes.
>>>>>5) addition of an _optional_ lookup() method that supports hints, to
>>>>>enable smooth migration from ComponentSelector usage
>>>>
>>>>-1s
>>>
>>> From a pure framework perspective I'm totally in agreement with the
>>>above (irrespective of the pain and suffering I'm enduring with respect
>>>to the metainfo/metadata issues inflicted by an unmentionable
>>>"Australia" personality). However, if we take into account ECM and the
>>>interest in facilitating a smooth migration path, I see only two
>>>alternative; either we provide a lookup( role, hint) in the framework
>>>(which I dislike in terms of the curent form being dicusssed), or (b) an
>>>extended CM is defintion at the excalibur level that provide a bridge
>>>from ECM to the emerging container models.
>>
>>Now, this thing of /hints/ got me thinking.
>>
>>As I said previously, it seems that:
>>
>>Role: what
>>Hint: how
>
>
> ...
>
>
>>ROLE: what it should do
>>CHARACTERIZATION: how it should do it
>>PREFERRED ACTOR: hint about *who* should do it
>
>
> nope.
>
> The role determines what part a component plays in your application; it
> is perfectly valid for the role to include information on the "how".
>
> Tight coupling of role to interface name is merely a convenience (it
> allows us to get away with easy casts).
I'm not so sure.
What do the Connection and SSLConnection components do?
Make a connection.
They use the same interfaces.
I should be able to say that I just need to make a connection or that I
need to make a *certain* type of connection.
If we say that SSLConnection is a role itself, it will not be given me.
The fact is that sometimes I want the container to decide for me,
sometimes I don't.
When the container decides, I just specify a role.
When I decide, I also specify a sub-role.
>>Well, this shows that hints are really not needed.
>
> yup. Except we have to take into account an already existing CS.
That use a hint as a sub-role usually.
>>The point is that we need a sub-role.
>>An interface (Role), tells me what to do, but does not specify how it
>>should be done.
>>This is not something that can be forgotten, as in the SSL case.
>>
>>I would deprecate hints in favor of sub-roles (or call them in a better
>>way, I'm no ace in names ;-)
>
> strings are pretty free-form. It is easy to describe both a role "king
> of all England" and a sub-role "mad" in a single string: "mad king of
> all England".
This is an implementation detail.
Or you do Role,SubRole or "role/subrole".
It's not a problem, but semantically there is a point in defining role
and subrole.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> >>> 2) removal of release()
>
> -1
>
> Still don't understand how I can deallocate a scarse resource as soon as
> possible :-/
> How the hell can I release a scarse resource right away?
> If processor hardware threads would never release() and use only a
> timeout, what processors would we have? :-S
>
> I agree that release is *not* compulsory for pooling, but I don't see
> replacements possible for handling of scarse resources.
=) We remove pooling from the CM alltogether. That's "removal of
release() from the CM (and putting the pool (with release() in the CM)".
> >>> 3) replacement of Component with Object
> >>
> >> +1s
>
> +1
>
> Why did we use _Component_ in the first place?
beautification.
> How can we make an Object be sure that it's being treated by an Avalon
> container?
we cannot (in a way expressed in java code). Is there a need?
> >>> 4) replacement of ComponentException with exists() for lookup()
>
> -1
>
> Exception throwing is a contract with the caller, that states that the
> caller is responsible for the Exception.
I think it most likely that the exception will just be rethrown from
compose(), so it ends up with the caller again.
> >>> 5) addition of an _optional_ lookup() method that supports hints, to
> >>> enable smooth migration from ComponentSelector usage
> >>
> >> -1s
> >
> > From a pure framework perspective I'm totally in agreement with the
> > above (irrespective of the pain and suffering I'm enduring with respect
> > to the metainfo/metadata issues inflicted by an unmentionable
> > "Australia" personality). However, if we take into account ECM and the
> > interest in facilitating a smooth migration path, I see only two
> > alternative; either we provide a lookup( role, hint) in the framework
> > (which I dislike in terms of the curent form being dicusssed), or (b) an
> > extended CM is defintion at the excalibur level that provide a bridge
> > from ECM to the emerging container models.
>
> Now, this thing of /hints/ got me thinking.
>
> As I said previously, it seems that:
>
> Role: what
> Hint: how
...
> ROLE: what it should do
> CHARACTERIZATION: how it should do it
> PREFERRED ACTOR: hint about *who* should do it
nope.
The role determines what part a component plays in your application; it
is perfectly valid for the role to include information on the "how".
Tight coupling of role to interface name is merely a convenience (it
allows us to get away with easy casts).
> Well, this shows that hints are really not needed.
yup. Except we have to take into account an already existing CS.
> The point is that we need a sub-role.
> An interface (Role), tells me what to do, but does not specify how it
> should be done.
> This is not something that can be forgotten, as in the SSL case.
>
> I would deprecate hints in favor of sub-roles (or call them in a better
> way, I'm no ace in names ;-)
strings are pretty free-form. It is easy to describe both a role "king
of all England" and a sub-role "mad" in a single string: "mad king of
all England".
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Robert Mouat <ro...@mouat.net>.
> -1 for now, but I have had a discussion off the list with Robert Mouat,
> that I believe has resulted in a replacement for release(). As soon
> as I get Robert's permission to post our exchange on the list I'll
> do it.
This email comes from the discussions I've had with Leo, justifying
suggestion I posted earlier
http://marc.theaimsgroup.com/?l=avalon-dev&m=102351424307838&w=2
[I've tidied up a little from what I sent Leo]
first some definitions:
resource:
things that you are concerned about running out of (e.g.
filehandles, database connections), but I'm going to explicitly
exclude memory (since it will be the job of the VMs GC to deal with
this).
This is similar to the concept of 'state', which may have been a
better term since I'm going to talk about transactions, but I want
to exclude memory.
[note: caching doesn't count -- this is specific to the
implementation of the component, and the component should have it's
own way of releasing cached resources before they run out].
transaction:
this is the period during which a component can be expected to hold
a [non-memory] resource. This depends a lot on the interface, and
I'm going to divide these into 3 categories:
1. The interface defines no transaction. e.g. those that can be
implemented in a thread-safe manner. e.g.
interface DocumentStore
{
public Document getDocument( String ref );
public void putDocument( String ref, Document doc );
}
2. The interface has its own transaction delineators.
e.g. open/close, or begin/end. These clearly define when the
transaction begins and ends, and there is no reason to suspect that
a component holds any resources after the close/end method is
called. [Since I'm really only considerating the end of the
transaction only the close/end method is needed]. An example of
this would be a SAX Transformer with its startDocument/endDocument
methods, or a non-componet example might be a java.io.InputStream
with its close method.
3. Finally there are interfaces which imply a transaction (i.e. that
the implementation may need to hold resources), but do not have any
methods delineating the transaction. The only example I can think
of for this one is not a component but the java.util.Iterator, which
has a next() method but no ending method.
The behaviour of the client is going to vary depending on which of the
3 cases above the interface falls into (is there room for ambiguity?).
I'll start with the easiest, (2) if the interface has its own
transaction delineators then there is no need for a release() method
because the component shouldn't be holding any resources after the
transaction has ended.
In case (3) we encounter some difficulties -- the client needs to tell
the component the transaction has ended, but there is no method to do
this. This is the situation where a XXXXXManager can be used... the
developer recognises that the interface lacks a means to explicitly
end the transaction and so requests XXXXXManager instead of
XXXXXComponent, so now the client can call release() on the
XXXXXManager.
Finally case (1), the interface implies no transaction. I'll split
this into two parts: (a) the implementation doesn't hold any resources
between method calls (again, caches don't count). This causes no
problems as a release() isn't needed. And finally the tricky one: (b)
the implementation holds resources...
So in (1.b) we have an interface that implies no transaction, and an
implementation that holds onto resources. I think that this is Bad
Design (tm) on behalf of the implementation... for example, if
DatabaseDocumentStore implemented DcoumentStore by holding open a
database connection for its entire lifetime (initialize->dispose).
Also this last case will cause problems whatever system is used. If a
specific XYZManager is given to the client there is no reason for it
to have a release() method (*). And even if there was a release() method
for the client to call, there seems little motivation for the client
to take advantage of it in a timely fashion (e.g. why not keep the
DocumentStore component for its entire lifetime).
Robert.
(*) If you want to argue that all XXXXXManagers should have a
release() method then why not save the client some trouble, see:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102373028626398&w=2
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Tue, 11 Jun 2002 22:45, Berin Loritsch wrote:
> However, some things like the Transformer selection is not as hard
> and fast. All the pipeline knows is it needs a transformer. The
> pipeline doesn't really care if it is an XSLT based transformer,
> a transformer that reads informatin from a database and inserts
> new elements, or some other custom transformer.
>
> The hint is a way of saying I need transformer X.
So a hint is not a hint but a constraint? :)
> Anyway, I want a satisfactory solution for these situations.
I still can't see what the problem with GeneratorManager, TransformerManager,
SerializerManager is
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 11 June 2002 08:45 am, Berin Loritsch wrote:
> But, you could always discourage the use of pooled *components*,
> and have individual components manage the scarce resources.
I believe that is the crux of pete d's position. lookup() should always
return something threadsafe.
Perhaps for pooled components we just need a generic PooledComponentManager.
Something ala
class Blah
{
PooledComponentManager pooled;
void compose( ComponentManager manager )
{
pooled = manager.lookup( ROLE );
}
void blah()
{
Component c = null;
try
{
c = pooled.get();
c.blahblah();
}
finally
{
pooled.release( c );
}
}
}
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > >>> 2) removal of release()
> >
> > -1
>
> -1 for now, but I have had a discussion off the list with
> Robert Mouat, that I believe has resulted in a replacement
> for release(). As soon as I get Robert's permission to post
> our exchange on the list I'll do it.
:) Combine a unique ComponentManager with my session proposal,
and you can reclaim a component in mid processing--and have
another instance finish processing. The point is that the
session object maintains the important information.
But, you could always discourage the use of pooled *components*,
and have individual components manage the scarce resources.
> > The problem, as Peter showed, is when I "hint" for a SSL
> > connection. If I get a normal connection, I *can* still
> > connect, but I *don't* want
> > it. In this case, the /hint/ is mandatory and cannot be overlooked.
>
> Seems like you're looking for a different ROLE, then:
>
> interface SSLConnectionManager extends ConnectionManager {};
>
> or is that too bulky?
Actually that would be the best thing.
However, some things like the Transformer selection is not as hard
and fast. All the pipeline knows is it needs a transformer. The
pipeline doesn't really care if it is an XSLT based transformer,
a transformer that reads informatin from a database and inserts
new elements, or some other custom transformer.
The hint is a way of saying I need transformer X.
Anyway, I want a satisfactory solution for these situations.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] avalon 5 ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
>
> Stephen McConnell wrote:
> >
> >
> > Peter Donald wrote:
> >
> >> At 10:21 AM 6/10/2002 +0200, you wrote:
> >>
> >>> - proposal for component management in avalon 5:
> >>> 1) removal of ComponentSelector
>
> +1 (I've done it too in my projects)
>
> >>> 2) removal of release()
>
> -1
-1 for now, but I have had a discussion off the list with Robert Mouat,
that I believe has resulted in a replacement for release(). As soon
as I get Robert's permission to post our exchange on the list I'll
do it.
> The problem, as Peter showed, is when I "hint" for a SSL
> connection. If I get a normal connection, I *can* still
> connect, but I *don't* want
> it. In this case, the /hint/ is mandatory and cannot be overlooked.
Seems like you're looking for a different ROLE, then:
interface SSLConnectionManager extends ConnectionManager {};
or is that too bulky?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> At 10:21 AM 6/10/2002 +0200, you wrote:
>>
>>> - proposal for component management in avalon 5:
>>> 1) removal of ComponentSelector
+1 (I've done it too in my projects)
>>> 2) removal of release()
-1
Still don't understand how I can deallocate a scarse resource as soon as
possible :-/
How the hell can I release a scarse resource right away?
If processor hardware threads would never release() and use only a
timeout, what processors would we have? :-S
I agree that release is *not* compulsory for pooling, but I don't see
replacements possible for handling of scarse resources.
>>> 3) replacement of Component with Object
>>
>> +1s
+1
Why did we use _Component_ in the first place?
So that the container could recognize an Avalon Component ad treat it as
such.
What was the need?
That the Component would be sure it got treated as such.
Now, the first part is unnecessary, and the current Service part shows
it. The fact is that the second part never worked!
And guess what: users still get confused and think that Components
somehow get magically called!!!
How can we make an Object be sure that it's being treated by an Avalon
container?
>>> 4) replacement of ComponentException with exists() for lookup()
-1
Exception throwing is a contract with the caller, that states that the
caller is responsible for the Exception.
Thinking that the callee can handle its own exceptions by itself is
wishful thinking.
Saying that the caller cannot do anything about it anyway is of no use,
since someone needs to do it.
>>> 5) addition of an _optional_ lookup() method that supports hints, to
>>> enable smooth migration from ComponentSelector usage
>>
>> -1s
>
> From a pure framework perspective I'm totally in agreement with the
> above (irrespective of the pain and suffering I'm enduring with respect
> to the metainfo/metadata issues inflicted by an unmentionable
> "Australia" personality). However, if we take into account ECM and the
> interest in facilitating a smooth migration path, I see only two
> alternative; either we provide a lookup( role, hint) in the framework
> (which I dislike in terms of the curent form being dicusssed), or (b) an
> extended CM is defintion at the excalibur level that provide a bridge
> from ECM to the emerging container models.
Now, this thing of /hints/ got me thinking.
As I said previously, it seems that:
Role: what
Hint: how
This means that if I ask for an XSLT processor, I can hint to use Saxon,
but it can give me also Crimson.
No problem for me, as long as it's XSLT spec compatible (ROLE).
The problem, as Peter showed, is when I "hint" for a SSL connection.
If I get a normal connection, I *can* still connect, but I *don't* want
it. In this case, the /hint/ is mandatory and cannot be overlooked.
This makes me think that there is something missing.
ROLE: what it should do
CHARACTERIZATION: how it should do it
PREFERRED ACTOR: hint about *who* should do it
Well, this shows that hints are really not needed.
Why would I want a specific actor!?!
Inversion of Control, it's the container that gives me the actor.
Why the heck would I need a container if I ask him everything?!?
The point is that we need a sub-role.
An interface (Role), tells me what to do, but does not specify how it
should be done.
This is not something that can be forgotten, as in the SSL case.
I would deprecate hints in favor of sub-roles (or call them in a better
way, I'm no ace in names ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 10:21 AM 6/10/2002 +0200, you wrote:
>
>> - proposal for component management in avalon 5:
>> 1) removal of ComponentSelector
>> 2) removal of release()
>> 3) replacement of Component with Object
>
>
> +1s
>
>
>> 4) replacement of ComponentException with exists() for lookup()
>> 5) addition of an _optional_ lookup() method that supports hints, to
>> enable smooth migration from ComponentSelector usage
>
>
> -1s
From a pure framework perspective I'm totally in agreement with the
above (irrespective of the pain and suffering I'm enduring with respect
to the metainfo/metadata issues inflicted by an unmentionable
"Australia" personality). However, if we take into account ECM and the
interest in facilitating a smooth migration path, I see only two
alternative; either we provide a lookup( role, hint) in the framework
(which I dislike in terms of the curent form being dicusssed), or (b) an
extended CM is defintion at the excalibur level that provide a bridge
from ECM to the emerging container models.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Leo Simons <le...@apache.org>.
> >4) replacement of ComponentException with exists() for lookup()
> >5) addition of an _optional_ lookup() method that supports hints, to
> >enable smooth migration from ComponentSelector usage
>
> -1s
okay. This will most likely lead (personal assessment) to cocoon using a
custom ComponentManager and possibly custom Container, and more
generally to people that use ECM/ECS having a tougher upgrade path.
Or to Avalon 5 being delayed.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] avalon 5 ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
At 10:21 AM 6/10/2002 +0200, you wrote:
>- proposal for component management in avalon 5:
>1) removal of ComponentSelector
>2) removal of release()
>3) replacement of Component with Object
+1s
>4) replacement of ComponentException with exists() for lookup()
>5) addition of an _optional_ lookup() method that supports hints, to
>enable smooth migration from ComponentSelector usage
-1s
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>