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 Sutic <le...@inspireinfrastructure.com> on 2002/06/12 13:39:43 UTC
[Summary] Avalon 5 ComponentManager interface
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: [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 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] 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 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 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>.
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>