You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/01/08 17:12:11 UTC
Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
I think we have come to the conclusion that Poolable interface is not
helpful, and makes certain things more difficult. The remainder of the
discussion has been what *else* people have found limiting. If Avalon
is not to be moved into absolescence, it must learn from its limitations.
Periodically we need to discuss what works and what does not work.
That is why we have the Lifestyle interfaces (real need) and Namespaces
for Configuration objects.
Paulo Gaspar wrote:
> Hi Berin,
>>Which is exactly what ExcaliburComponentManager does. There are necessary
>>improvements, but they will come.
>>
>
> It is quite different:
> I have also a kind of "ComponentHandler", with a different name but
> which implementation is also dependent on the type of the component's
> lifecycle.
The ComponentHandler uses a ComponentFactory that handles the initialization
and destruction phases of a Component. The Container is responsible for the
runtime phases (i.e. suspend()/re*()/resume() cycles). In the "big" picture,
the ComponentHandler determines when to create a new instance of a Component
and when to destroy an instance of a Component. The Container works with
the ComponentHandler.
ExcaliburComponentManager/Selector have the three lifestyles: ThreadSafe,
SingleThreaded, Poolable. The Poolable interface we all agree is not beneficial
to the system as a whole. Also, having Components that are used only once
is not a good pattern as it adds undue stress on the garbage collecter and
only adds to the latency of looking up a Component. Therefore the point
of the original thread was to merge SingleThreaded and Poolable so that
all SingleThreaded Components are pooled.
> There is no "DefaultComponentFactory". Each type of component has its
> specific factory. This factory takes care of configuration too.
In essence, you have merged the ComponentHolder and ComponentFactory into
one class. The ComponentFactory gives the Configuration information to the
Component. This works well in most situations.
> (Much of this configuration cab be eased using a "configuration bean"
> a Configurer and a Converter, like Peter did on Ant Myrmidon proposal
> ...although my code already went a lot beyond what was there some 3
> months ago.)
:) This is one of the things I am working on. A completely managed solution.
By using a number of "Managers" all working independantly on different parts
of the system. That way, the users of the Managed Container only have to
worry about the Components and how they are mapped together in a system--all
reconfiguration and logger remapping are done automatically.
Perhaps this goes beyond what you are thinking of. However, such a managed
system is able to make expensive decisions about the most efficient way to
allocate resources asynchronously from the rest of the system. That way
latencies involved in lookup and releasing of components are minimized to
simple get() and put() calls on a Map.
> My "ComponentHandler" still takes care of lifecycle management
> operations and strategies, like:
> - Initializing, starting, stopping, disposing, etc.
> - Using only one instance for thread safe components and always a new
> instance for the others.
That is the implementer's perogative on how they want to manage their system
or define Components. However, if your system does not work with any Avalon
Component, then you have lost the ability to use a number of well tested
Components. Hopefully you have not lost that ability.
> Of course.
> I am just using the opportunity to throw some doubt on other markers too.
> =;o)
Which is why I changed the name of this thread.
>>>>The next question is why make everything more "bean" like. JavaBeans,
>>>>while usable, do have a distinct disadvantage in that they are not
>>>>clearly marked.
>>>>
>>>>
>>>I do not see much use for most pure (no methods) markers. I ended up
>>>deleting them some 3 months ago and I do not miss them a bit.
>>>
>>The Idea of a Component being marked explicitly as a Component does
>>have some value to me. It forces you to think in terms of what a
>>Component
>>is supposed to do. That way you don't run into the JavaBeans antipattern
>>of everything (data objects included) being a Bean. You encapsulate
>>data accessor logic apart from the data itself. It is not a correct
>>pattern to implement Data as a Component.
>>
>
> The above mentioned specific factory per component class takes care of
> that.
It seems like alot of work for a Component writer to create a new factory
for each Component. I beleive that slows development time unnecessarily.
By having one generic ComponentFactory, you can focus on more important
issues like Component interaction, and how it should handle when Components
are not available.
> Precisely, although I often (ab)use an abstract class that puts
> together 3 of them (Initializable, Disposable and Startable) just to
> ease implementing some LifeCycle validation:
> - Checking if the component is active;
> - Making sure it is not started before being intialized;
> - etc.
>
> Of course that I end up with some empty methods, but most of those
> components have no performance issues.
Again, your perogative to do this. I am sure you do this so that you
limit the number of Factories you have to create. Again, I think it
is wasteful to have to write a Factory for every type of Component,
but it is your perogative as to how you manage your Components. Avalon
as a framework does not enforce a specific algorithm--only a specific
interface
>>>>A Role defines the logical use of the Component in the system. If
>>>>the Role interface extends the Component interface, all the hard
>>>>work is done for you and you don't have to recast the Component
>>>>to release it.
>>>>
>>>I understand and I do not have to recast any component since my
>>>component manager returns Object instead of Component.
Of course, in either case, you have to cast it to use it.
>>>
>>And if your Role interface extends Component, you have the same
>>convenience--while maintaining the protection that forces you to
>>separate data and the interface to get the data.
>>
>
> Again, the above mentioned factory makes my aware of that.
I won't belabor this point. I just know that a "ComponentManager"
that deals with Objects is open to abuse by less disciplined people
than yourself. For a framework, I am not convinced if it is
proper. Of course, I am open to understanding the motivation for
it.
>>>Since I focus on building components that are as independent from
>>>the framework as possible (which makes them more reusable) I always
>>>use a component factory. Even if only to take care of configuration.
>>>
>>That's fine. I just would have a hard time with a ComponentManager
>>that is really simply an ObjectManager. That would be bad.
>>
>
> I believe it is a ComponentManager... and one with several extra tasks.
> But that has to do with the specifics of this project.
By extending the ComponentManager interface, you can handle those extra
tasks (hopefully).
The problem with ExcaliburComponentManager is that it is not *just* a
ComponentManager, but it is also a Container. That is merging too many
concerns, and I want to separate the Container code from the Component
Management code. It is best when the ComponentManager only manages access
to Components.
>>>I am only focusing on the parts of what I have that can be done in
>>>Avalon since what I have is quite a bit different.
>>>
>>How much so?
>>
>
> Quite a lot because of the way I choused to lookup components (by role
> AND a name), with many components for the same role, some with default
> configuration parameters, component tracker per requester, etc.
I have some questions on the lookup by role and name. Because Avalon
as a framework is only concerned with the interface and enough contracts
to specify results (not methodology), the default configuration params and
component tracking is orthagonal to this discussion. You are perfectly
able to do that and have your system be fully Avalon compliant.
The question comes when you feel it is necessary to change the interface
of the ComponentManager. Either Avalon is not doing something correctly,
or it may be able to learn something.
Therefore, I want to get some more information on why you felt it necessary
to change interfaces.
As to Component Management, we have discussed many ideas before we came up
with what we have now. Among them were JNDI, strict ComponentManager (i.e.
it was considered wrong to have multiple components for a role),
NamedComponentManager (with your lookup by role and name), and the current
ComponentManager/Selector approach.
Many times, use has tempered our views of the world. Our personal experience
deems what is more natural for us to use, and how we view our world. Cocoon
started out down the path of the NamedComponentManager. I don't think it
was correct for the NamedComponent interface, but it did have a certain
simplicity.
The question arose when we have n-dimensional needs for gaining access to a
Component. For instance, a ComponentManager addresses one dimension: role.
ComponentSelector defines a purposely loose contract so that you can use
any object or query objects to address all the extra dimensions that might
arise for future systems.
The ComponentSelector adds a little bit of Complexity to the overall system,
and an additional lookup step. In my communications with other CBD frameworks,
there are other approaches we have not considered yet (or if we have, I don't
recall).
It is most common to use JNDI in J2EE frameworks. However, we have already
ruled that out for Avalon as it is too heavy for resource constrained
environments.
Another interesting approach is the use of a Query object to lookup the
required component. The one Query object addresses as many dimensions as
is necessary in the system to lookup the correct component. This can include
role, name, locale, and session information into the one lookup request.
The manager, as it were, would make choices based on the information in the
Query Object. That would allow the Components for which there was one
entry for the role to return immediately. For Components that required even
more information, the next part of the Query object was used.
That does present some nice ways of expressing a system. The problem is creating
a Query Object for every type of Component you have to deal with. In the Cocoon
world, the Environment would be a perfect part of the Query Object as it addresses
all dimensions of the problem space other than role.
> At first you do not see the differences. The essence looks the same.
> It looks like I could do it the Avalon way.
You probably could ;)
> It is because my problem domain is so different from Avalon's that I
> ended up finding that a lot could be made much simpler by changing
> the way the ComponentManager related stuff works.
And that is why I want to learn from you.
>
> That added complexity to the ComponentManager (still not very big) but
> simplified a lot the overall project.
>
>
> It is just one of those things that you have to play a lot with to
> understand why.
Well a short history of the decision process would help alot more than
playing with it.
> Notice that I followed a different approach than Cocoon, where the
> sitemap has almost nothing to do with the ComponentManager.
>
> In my implementation, the sitemap is stored in the ComponentManager.
> Overall, my implementation is much, much, much simpler.
Cocoon's Sitemap is stored in a ComponentManager as well. It just needs
access to a large number of other Components.
> I am not saying that Cocoon could be implemented this way. I am not
> sure about that even after using quite some Cocoon code. These are
> two different beasts, with different objectives although with many
> things in common.
You are right. Cocoon can't be implemented that way, but it can be
cleaned up some in this regard. They are very different beasts.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Tuesday 08 January 2002 11:38 am, Berin Loritsch wrote:
> I am familiar with the scenario. The problem is really in the
> implementation. The Parser Component was implemented in such a way as the
> Parser instance was tied to the SAXReader instance.
<snip/>
> In hindsight, it was incorrect to make the Parser Component SingleThreaded.
> The implementation of the Component should have been changed.
ok, I wasn't aware of all the gory details, I just wanted to make sure all
scenarios were covered, and it sounds like they are :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Tuesday 08 January 2002 11:12 am, Berin Loritsch wrote:
>
>>Therefore the point of the original thread was to merge SingleThreaded and
>>Poolable so that all SingleThreaded Components are pooled.
>>
>
> I believe Cocoon made use of the SingleThreaded interface explicitly a few
> months ago when there were problems with a Xerces instance not being able to
> be reset properly after having experienced a SAXException.
>
> I do agree with the removal of Poolable and making the default for components
> to be Poolable if not ThreadSafe, but I would suggest leaving SingleThreaded
> so a component could be turned into a pure factory if need be. Granted it
> would likely be the exception rather than the rule, but I think it would be
> good to leave that functionality in there.
> -pete
I am familiar with the scenario. The problem is really in the implementation.
The Parser Component was implemented in such a way as the Parser instance was
tied to the SAXReader instance.
In reality, the Parser component can be implemented as ThreadSafe. The pool
of SAXReaders would be managed by returning the SAXReader once endDocument()
was called.
The problem in the end is not so much that the Component was forced to be
SingleThreaded by it's interface (like Generator, et al), but that it's
implementation was incorrect because of some faulty assumptions.
In hindsight, it was incorrect to make the Parser Component SingleThreaded.
The implementation of the Component should have been changed.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Tuesday 08 January 2002 11:12 am, Berin Loritsch wrote:
> Therefore the point of the original thread was to merge SingleThreaded and
> Poolable so that all SingleThreaded Components are pooled.
I believe Cocoon made use of the SingleThreaded interface explicitly a few
months ago when there were problems with a Xerces instance not being able to
be reset properly after having experienced a SAXException.
I do agree with the removal of Poolable and making the default for components
to be Poolable if not ThreadSafe, but I would suggest leaving SingleThreaded
so a component could be turned into a pure factory if need be. Granted it
would likely be the exception rather than the rule, but I think it would be
good to leave that functionality in there.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Ah! I should have read this post before answering the previous!
That is even BETTER!
=:o)
It is simpler and not creating a class makes all the sense for
something not used very often.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 5:36 AM
> To: Avalon Developers List
> Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> On Fri, 11 Jan 2002 09:56, Peter Donald wrote:
> > On Fri, 11 Jan 2002 01:51, Paulo Gaspar wrote:
> > > Wouldn't an adapter class for such especial cases be adequate?
> > > Something like (just a draft):
> >
> > Similar to what I did. Except mine looked like
> >
> > > public class LogLevel extends ValuedEnum
> > > implements Serializable
> > > {
> > > private final static Map m_levelMap = new HashMap(5);
> > >
> > > public final static LogLevel DEBUG = new
> LogLevel("DEBUG", 5);
> > > public final static LogLevel INFO = new
> LogLevel("INFO", 10);
> > > public final static LogLevel WARN = new
> LogLevel("WARN", 15);
> > > public final static LogLevel ERROR = new
> LogLevel("ERROR", 20);
> > > public final static LogLevel FATAL_ERROR = new
> > > LogLevel("FATAL_ERROR", 25);
> >
> > public static void log( final String message, LogLevel level )
> > {
> > ...do if statement here...
> > }
>
> of course I meant to pass in a Logger to here:)
>
>
> >
> > > private LogLevel(final String i_name, final int i_value)
> > > {
> > > super(i_name, i_value, m_levelMap);
> > > }
> > >
> > > public static LogLevel getLevelForName(final String i_levelName)
> > > {
> > > return (LogLevel)m_levelMap.get(i_levelName.toUpperCase());
> > > }
> > >
> > > public String toString()
> > > {
> > > return "LogLevel[" + getName() + "/" + getValue() + "]";
> > > }
> > >
> > > private Object readResolve()
> > > throws ObjectStreamException
> > > {
> > > return getLevelForName(getName());
> > > }
> > > }
> > >
> > > This would allow to keep the current "clean" interface and
> > > use this class just for those especial cases.
> > >
> > > What do you think?
> >
> > Either way is good ;)
>
> --
> Cheers,
>
> Pete
>
> ------------------------------------------------------------
> militant agnostic: i don't know, and you don't know either.
> ------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 11 Jan 2002 09:56, Peter Donald wrote:
> On Fri, 11 Jan 2002 01:51, Paulo Gaspar wrote:
> > Wouldn't an adapter class for such especial cases be adequate?
> > Something like (just a draft):
>
> Similar to what I did. Except mine looked like
>
> > public class LogLevel extends ValuedEnum
> > implements Serializable
> > {
> > private final static Map m_levelMap = new HashMap(5);
> >
> > public final static LogLevel DEBUG = new LogLevel("DEBUG", 5);
> > public final static LogLevel INFO = new LogLevel("INFO", 10);
> > public final static LogLevel WARN = new LogLevel("WARN", 15);
> > public final static LogLevel ERROR = new LogLevel("ERROR", 20);
> > public final static LogLevel FATAL_ERROR = new
> > LogLevel("FATAL_ERROR", 25);
>
> public static void log( final String message, LogLevel level )
> {
> ...do if statement here...
> }
of course I meant to pass in a Logger to here:)
>
> > private LogLevel(final String i_name, final int i_value)
> > {
> > super(i_name, i_value, m_levelMap);
> > }
> >
> > public static LogLevel getLevelForName(final String i_levelName)
> > {
> > return (LogLevel)m_levelMap.get(i_levelName.toUpperCase());
> > }
> >
> > public String toString()
> > {
> > return "LogLevel[" + getName() + "/" + getValue() + "]";
> > }
> >
> > private Object readResolve()
> > throws ObjectStreamException
> > {
> > return getLevelForName(getName());
> > }
> > }
> >
> > This would allow to keep the current "clean" interface and
> > use this class just for those especial cases.
> >
> > What do you think?
>
> Either way is good ;)
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Does that mean you put everything in one single class?
The question is because you just added a STATIC
public static void log( final String message, LogLevel level )
...and no constructor with a Logger parameter and no inheritance
from a Logger. (You probably did it in a hurry so you could go
back coding. (o:= )
I am just checking if that is the idea - merging the 2 classes
in my post - which for me makes all the sense and is a nicer
variation.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Thursday, January 10, 2002 11:56 PM
> To: Avalon Developers List
> Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> On Fri, 11 Jan 2002 01:51, Paulo Gaspar wrote:
> > Wouldn't an adapter class for such especial cases be adequate?
> > Something like (just a draft):
>
> Similar to what I did. Except mine looked like
> > public class LogLevel extends ValuedEnum
> > implements Serializable
> > {
> > private final static Map m_levelMap = new HashMap(5);
> >
> > public final static LogLevel DEBUG = new
> LogLevel("DEBUG", 5);
> > public final static LogLevel INFO = new
> LogLevel("INFO", 10);
> > public final static LogLevel WARN = new
> LogLevel("WARN", 15);
> > public final static LogLevel ERROR = new
> LogLevel("ERROR", 20);
> > public final static LogLevel FATAL_ERROR = new
> LogLevel("FATAL_ERROR",
> > 25);
> >
> public static void log( final String message, LogLevel level )
> {
> ...do if statement here...
> }
>
> >
> > private LogLevel(final String i_name, final int i_value)
> > {
> > super(i_name, i_value, m_levelMap);
> > }
> >
> > public static LogLevel getLevelForName(final String i_levelName)
> > {
> > return (LogLevel)m_levelMap.get(i_levelName.toUpperCase());
> > }
> >
> > public String toString()
> > {
> > return "LogLevel[" + getName() + "/" + getValue() + "]";
> > }
> >
> > private Object readResolve()
> > throws ObjectStreamException
> > {
> > return getLevelForName(getName());
> > }
> > }
>
> > This would allow to keep the current "clean" interface and
> > use this class just for those especial cases.
> >
> > What do you think?
>
> Either way is good ;)
>
> --
> Cheers,
>
> Pete
>
> ----------------------------------------
> "Liberty means responsibility. That is
> why most men dread it." - Locke
> ----------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 11 Jan 2002 01:51, Paulo Gaspar wrote:
> Wouldn't an adapter class for such especial cases be adequate?
> Something like (just a draft):
Similar to what I did. Except mine looked like
> public class LogLevel extends ValuedEnum
> implements Serializable
> {
> private final static Map m_levelMap = new HashMap(5);
>
> public final static LogLevel DEBUG = new LogLevel("DEBUG", 5);
> public final static LogLevel INFO = new LogLevel("INFO", 10);
> public final static LogLevel WARN = new LogLevel("WARN", 15);
> public final static LogLevel ERROR = new LogLevel("ERROR", 20);
> public final static LogLevel FATAL_ERROR = new LogLevel("FATAL_ERROR",
> 25);
>
public static void log( final String message, LogLevel level )
{
...do if statement here...
}
>
> private LogLevel(final String i_name, final int i_value)
> {
> super(i_name, i_value, m_levelMap);
> }
>
> public static LogLevel getLevelForName(final String i_levelName)
> {
> return (LogLevel)m_levelMap.get(i_levelName.toUpperCase());
> }
>
> public String toString()
> {
> return "LogLevel[" + getName() + "/" + getValue() + "]";
> }
>
> private Object readResolve()
> throws ObjectStreamException
> {
> return getLevelForName(getName());
> }
> }
> This would allow to keep the current "clean" interface and
> use this class just for those especial cases.
>
> What do you think?
Either way is good ;)
--
Cheers,
Pete
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer at the end... just before the bunch of code:
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@osm.net]
> Sent: Thursday, January 10, 2002 2:40 PM
>
> Quick note:
>
> I was really pleased to see this suggestion - because I'm
> currently dealing with a number of issued concerning the
> OpenORB project and basically, the notion of debugging
> priority is the only thing I'm missing to be able to
> do a clean migration from what currently exists to
> something rational. Please consider this as strong
> plus one to the addition of logging levels.
>
> Cheers, Steve,
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:peter@apache.org]
> > Sent: Thursday, 10 January, 2002 14:07
> >
> > On Thu, 10 Jan 2002 14:09, Paulo Gaspar wrote:
> > > Hi again, answer inline:
> >
> > Hi !
> >
> > > > * consider adding a Level object to logger and extra methods
> > > >
> > > > log( Level, message )
> > > > log( Level, message, exception )
> > >
> > > Argh! I used to believe on that one and then went the Avalon
> > > way. I find the interface much cleaner.
> > >
> > > Which experience makes you change your mind on this one?
> >
> > basically when you have other objects that adapt from some other
> > source to log messages. For instance say you have the standard
> > output of process redirected into a logger or redirting data from
> > another toolkit or whatever.
> >
> > --
> > Cheers,
> >
> > Pete
Wouldn't an adapter class for such especial cases be adequate?
Something like (just a draft):
public class LoggerByLevel
{
private final Logger m_logger;
public LoggerByLevel(final Logger i_logger)
{
m_logger = i_logger;
}
public final void log(LogLevel i_level, final String i_message )
{
if (LogLevel.DEBUG.isEqualTo(i_level))
{
m_logger.debug(i_message);
}
else if (LogLevel.INFO.isEqualTo(i_level))
{
m_logger.info(i_message);
}
else if (LogLevel.WARN.isEqualTo(i_level))
{
m_logger.warn(i_message);
}
else if (LogLevel.ERROR.isEqualTo(i_level))
{
m_logger.error(i_message);
}
else if (LogLevel.FATAL_ERROR.isEqualTo(i_level))
{
m_logger.fatalError(i_message);
}
else
{
m_logger.debug(i_message);
}
}
public final void log(LogLevel i_level, final String i_message, final Throwable i_throwable)
{
if (LogLevel.DEBUG.isEqualTo(i_level))
{
m_logger.debug(i_message, i_throwable);
}
else if (LogLevel.INFO.isEqualTo(i_level))
{
m_logger.info(i_message, i_throwable);
}
else if (LogLevel.WARN.isEqualTo(i_level))
{
m_logger.warn(i_message, i_throwable);
}
else if (LogLevel.ERROR.isEqualTo(i_level))
{
m_logger.error(i_message, i_throwable);
}
else if (LogLevel.FATAL_ERROR.isEqualTo(i_level))
{
m_logger.fatalError(i_message, i_throwable);
}
else
{
m_logger.debug(i_message, i_throwable);
}
}
}
***************************************************
Having a LogLevel implemented this way:
***************************************************
public class LogLevel extends ValuedEnum
implements Serializable
{
private final static Map m_levelMap = new HashMap(5);
public final static LogLevel DEBUG = new LogLevel("DEBUG", 5);
public final static LogLevel INFO = new LogLevel("INFO", 10);
public final static LogLevel WARN = new LogLevel("WARN", 15);
public final static LogLevel ERROR = new LogLevel("ERROR", 20);
public final static LogLevel FATAL_ERROR = new LogLevel("FATAL_ERROR", 25);
private LogLevel(final String i_name, final int i_value)
{
super(i_name, i_value, m_levelMap);
}
public static LogLevel getLevelForName(final String i_levelName)
{
return (LogLevel)m_levelMap.get(i_levelName.toUpperCase());
}
public String toString()
{
return "LogLevel[" + getName() + "/" + getValue() + "]";
}
private Object readResolve()
throws ObjectStreamException
{
return getLevelForName(getName());
}
}
This would allow to keep the current "clean" interface and
use this class just for those especial cases.
What do you think?
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Stephen McConnell <mc...@osm.net>.
Quick note:
I was really pleased to see this suggestion - because I'm
currently dealing with a number of issued concerning the
OpenORB project and basically, the notion of debugging
priority is the only thing I'm missing to be able to
do a clean migration from what currently exists to
something rational. Please consider this as strong
plus one to the addition of logging levels.
Cheers, Steve,
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Thursday, 10 January, 2002 14:07
> To: Avalon Developers List
> Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> On Thu, 10 Jan 2002 14:09, Paulo Gaspar wrote:
> > Hi again, answer inline:
>
> Hi !
>
> > > * consider adding a Level object to logger and extra methods
> > >
> > > log( Level, message )
> > > log( Level, message, exception )
> >
> > Argh! I used to believe on that one and then went the Avalon
> > way. I find the interface much cleaner.
> >
> > Which experience makes you change your mind on this one?
>
> basically when you have other objects that adapt from some other
> source to log messages. For instance say you have the standard
> output of process redirected into a logger or redirting data from
> another toolkit or whatever.
>
> --
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | Hlade's Law: If you have a difficult task, give it |
> | to a lazy person -- they will find an easier |
> | way to do it. |
> *------------------------------------------------------*
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Thu, 10 Jan 2002 14:09, Paulo Gaspar wrote:
> Hi again, answer inline:
Hi !
> > * consider adding a Level object to logger and extra methods
> >
> > log( Level, message )
> > log( Level, message, exception )
>
> Argh! I used to believe on that one and then went the Avalon
> way. I find the interface much cleaner.
>
> Which experience makes you change your mind on this one?
basically when you have other objects that adapt from some other source to
log messages. For instance say you have the standard output of process
redirected into a logger or redirting data from another toolkit or whatever.
--
Cheers,
Pete
*------------------------------------------------------*
| Hlade's Law: If you have a difficult task, give it |
| to a lazy person -- they will find an easier |
| way to do it. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 10:50 PM
>
>
> On Sat, 12 Jan 2002 02:08, Paulo Gaspar wrote:
> > > "The ability to quote is a serviceable substitute for wit." -- Maugham
> >
> > You sure have a good source of quotes!
>
> Took me years to collect em all ;)
>
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> "Sometimes its better to keep your mouth shut and
> let people think your an idiot, than to open it
> and remove all doubt."
> -------------------------------------------------
And this is a very cool one that I never remember...
=;o)
Have fun,
Paulo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 02:08, Paulo Gaspar wrote:
> > "The ability to quote is a serviceable substitute for wit." -- Maugham
>
> You sure have a good source of quotes!
Took me years to collect em all ;)
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi again, just a couple of tiny remarks...
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 3:21 PM
>
>
> On Sat, 12 Jan 2002 00:44, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > On Fri, 11 Jan 2002 02:26, Berin Loritsch wrote:
> > >>>BTW, do we dump the Component interface?
> > >>
> .......................
> >
> > Ok. I was also thinking of how to provide a hint to the
> Container that the
> > Component needed to be pooled.
> >
> > How do you propose that we address the issue of programatically
> providing
> > the hint that a Component is pooled. Is this something we have
> to do with
> > the Manifest file? What is the proper method in your mind?
>
> I think thats a different issue. Marker interfaces are one option,
> declarations in a descriptor file is another better option (but more
> heavyweight) and manifest entries seem a bit crusty to me ;)
A method in a custom component factory is another, as described in
my other post.
> However I don't think we should have an interface named Component
> that has a
> release method or anything similar. If you really need such a generic
> interface (though I am not so sure about that) then name it Releasable or
> something similar.
>
> However I only think that this sort of functionality works on "shallow"
> components. For instance pooled JDBC connections are a good
> example (not sure
> if this is how excaliburs pool works but ...). Most of the
> methods just store
> a little bit of state and then directly delegate to the "real" connection.
>
> When you do close it will release all the resources in "real"
> connection then
> null out the real connection. Thus any attempt to reuse that particular
> connection (which is just a lightweigh facade) will fail.
That is exactly how my implementation and others work.
=:o)
> I think that is the only case where a component should be allowed
> to have a
> close()/release() method actually mean "return me to pool". In
> other cases I
> think it should be up to the user to replace the component or
> optionally a
> "transaction" of components (like described in other mail" could be used.
>
> --
> Cheers,
>
> Pete
>
> "The ability to quote is a serviceable substitute for wit." -- Maugham
You sure have a good source of quotes!
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 00:44, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Fri, 11 Jan 2002 02:26, Berin Loritsch wrote:
> >>>BTW, do we dump the Component interface?
> >>
> >>I think that is the general consensus. However I do have one more use
> >> for it:
> >>
> >>If we move the release() method from ComponentManager, and place it in
> >> the Component interface, then Components that require releasing because
> >> they are pooled have a mechanism to do so. That policy should be
> >> decided by the work interface. For example: a component that extends
> >> ContentHandler cannot be threadsafe, so it would implement the Component
> >> interface--but a component that does not need to be pooled by virtue of
> >> the work interface would not implement the Component interface.
> >
> > I think it should be solely up to the work interface to release the
> > component if the component is actually just a shallow facade ontop of a
> > real resource. For instance close() when used on a JDBC connection would
> > place the real underlying resource back in pool. Similar methods will be
> > used with other resources/components but I don't think we should have a
> > Component interface provide such a method.
>
> Ok. I was also thinking of how to provide a hint to the Container that the
> Component needed to be pooled.
>
> How do you propose that we address the issue of programatically providing
> the hint that a Component is pooled. Is this something we have to do with
> the Manifest file? What is the proper method in your mind?
I think thats a different issue. Marker interfaces are one option,
declarations in a descriptor file is another better option (but more
heavyweight) and manifest entries seem a bit crusty to me ;)
However I don't think we should have an interface named Component that has a
release method or anything similar. If you really need such a generic
interface (though I am not so sure about that) then name it Releasable or
something similar.
However I only think that this sort of functionality works on "shallow"
components. For instance pooled JDBC connections are a good example (not sure
if this is how excaliburs pool works but ...). Most of the methods just store
a little bit of state and then directly delegate to the "real" connection.
When you do close it will release all the resources in "real" connection then
null out the real connection. Thus any attempt to reuse that particular
connection (which is just a lightweigh facade) will fail.
I think that is the only case where a component should be allowed to have a
close()/release() method actually mean "return me to pool". In other cases I
think it should be up to the user to replace the component or optionally a
"transaction" of components (like described in other mail" could be used.
--
Cheers,
Pete
"The ability to quote is a serviceable substitute for wit." -- Maugham
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin, answer at the end...
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, January 11, 2002 2:44 PM
>
> ...
>
> > I think it should be solely up to the work interface to release
> the component
> > if the component is actually just a shallow facade ontop of a
> real resource.
> > For instance close() when used on a JDBC connection would place
> the real
> > underlying resource back in pool. Similar methods will be used
> with other
> > resources/components but I don't think we should have a
> Component interface
> > provide such a method.
>
>
> Ok. I was also thinking of how to provide a hint to the
> Container that the
> Component needed to be pooled.
>
> How do you propose that we address the issue of programatically
> providing the
> hint that a Component is pooled. Is this something we have to do with the
> Manifest file? What is the proper method in your mind?
>
>
> It is easy to deal with Components that implement a marker
> interface when that
>
> interface has semantic meaning that is understood. That is why
> the ThreadSafe
> and SingleThreaded interfaces are currently useful. If we remove
> the marker
> interfaces, we have to replace them with some other method.
>
> The critical thing we have to address is whether a Component
> should be unique
> to each lookup, or whether the same instance can be used accross
> all lookups.
> Cocoon has proven unequivacably that pooling Components provides
> a serious boost
> in runtime performance and scalability. Furthermore, the cost of
> synchronizing
> access to critical sections of logic in a Component is cheaper
> than pooling.
>
> That is why this lifestyle aspect is so important.
IMO you could have 2 ways of creating a component:
1) Generic factory;
2) Custom factory.
In my experience 2) is enough and tends to produce components with
more chances for reuse since you can usually place all framework
dependencies (configuration included) in the factory and have
components that can be used even without the framework.
Besides, 2) does NOT produce much extra work. Actually, it helps
my auto-configuration mechanism to work in such a way that the
codes gets much shorter than in the traditional Avalon way.
But you could still have 1) with markers. It is not a mutual
exclusive option.
With 1) the CM would always find the lifestyle of a component by
asking its factory and the factory would know the component's
lifecycle by checking what marker interfaces it implemented.
What do you think about this option?
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 11 Jan 2002 02:26, Berin Loritsch wrote:
>
>>>BTW, do we dump the Component interface?
>>>
>>I think that is the general consensus. However I do have one more use for
>>it:
>>
>>If we move the release() method from ComponentManager, and place it in the
>>Component interface, then Components that require releasing because they
>>are pooled have a mechanism to do so. That policy should be decided by the
>>work interface. For example: a component that extends ContentHandler
>>cannot be threadsafe, so it would implement the Component interface--but a
>>component that does not need to be pooled by virtue of the work interface
>>would not implement the Component interface.
>>
>
> I think it should be solely up to the work interface to release the component
> if the component is actually just a shallow facade ontop of a real resource.
> For instance close() when used on a JDBC connection would place the real
> underlying resource back in pool. Similar methods will be used with other
> resources/components but I don't think we should have a Component interface
> provide such a method.
Ok. I was also thinking of how to provide a hint to the Container that the
Component needed to be pooled.
How do you propose that we address the issue of programatically providing the
hint that a Component is pooled. Is this something we have to do with the
Manifest file? What is the proper method in your mind?
It is easy to deal with Components that implement a marker interface when that
interface has semantic meaning that is understood. That is why the ThreadSafe
and SingleThreaded interfaces are currently useful. If we remove the marker
interfaces, we have to replace them with some other method.
The critical thing we have to address is whether a Component should be unique
to each lookup, or whether the same instance can be used accross all lookups.
Cocoon has proven unequivacably that pooling Components provides a serious boost
in runtime performance and scalability. Furthermore, the cost of synchronizing
access to critical sections of logic in a Component is cheaper than pooling.
That is why this lifestyle aspect is so important.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 11 Jan 2002 02:26, Berin Loritsch wrote:
> > BTW, do we dump the Component interface?
>
> I think that is the general consensus. However I do have one more use for
> it:
>
> If we move the release() method from ComponentManager, and place it in the
> Component interface, then Components that require releasing because they
> are pooled have a mechanism to do so. That policy should be decided by the
> work interface. For example: a component that extends ContentHandler
> cannot be threadsafe, so it would implement the Component interface--but a
> component that does not need to be pooled by virtue of the work interface
> would not implement the Component interface.
I think it should be solely up to the work interface to release the component
if the component is actually just a shallow facade ontop of a real resource.
For instance close() when used on a JDBC connection would place the real
underlying resource back in pool. Similar methods will be used with other
resources/components but I don't think we should have a Component interface
provide such a method.
--
Cheers,
Pete
--------------------------------------------------
you've made a dangerous leap right over common
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 10 January 2002 10:51 am, Berin Loritsch wrote:
> >>Are we going to make lookup() not throw a ComponentException
> >>anymore? If not, (or unless ComponentException extends
> >>RuntimeException) I don't see how the t/c/f block will go away, as
> >>you still have to trap the ComponentException.
>
> No, ComponentException still exists. The t/c/f block goes away if we
> do not have to return any of the components back to the ComponentManager,
> and the method throws the ComponentException.
How far up the call stack would you recommend allowing ComponentException to
go?
Say I have a method doSomething() on a component that as part of running
looks up another component. Should doSomething() then throw
ComponentException?
I view a failure in lookup up a component a runtime problem, similar to how
the Context throws an IllegalStateException if you try to put() when it is
read-only. I'm curious as to the design intent :)
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Peter Royal wrote:
>
>>Sent: Thursday, 10 January, 2002 16:38
>>To: Avalon Developers List
>>Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>>
>>
>>On Thursday 10 January 2002 10:26 am, Berin Loritsch wrote:
>>
>>>This approach simplifies the use of the Component infrastructure
>>>tremendously as we no longer have to have big complex try/catch/finally
>>>methods to ensure that we release all components even if they are
>>>ThreadSafe.
>>>
>>Are we going to make lookup() not throw a ComponentException
>>anymore? If not, (or unless ComponentException extends
>>RuntimeException) I don't see how the t/c/f block will go away, as
>>you still have to trap the ComponentException.
No, ComponentException still exists. The t/c/f block goes away if we
do not have to return any of the components back to the ComponentManager,
and the method throws the ComponentException.
>>
>>On a side note, I always re-throw any ComponentException's as
>>RuntimeException's, what do other folk do?
>>
>
> I generally rethrow a qualified ComponentException (qualified in
> that it has meaningful context in the exception message).
>
> Steve.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal [mailto:proyal@managingpartners.com]
> On Thursday 10 January 2002 12:48 pm, Stephen McConnell wrote:
> > understand correctly, under Phoenix the proxies etc. are already
> > instantiated .. is there a real benefit in delaying a lookup
> > invocation ?
>
> I delay lookup in ThreadSafe components that access Pooled ones. Take a
> component that accessed the database for example. It is ThreadSafe, but I
> don't want to just grab a single connection upon component
> initialization.
> Rather as a data-accessing method is called, it gets a DB
> connection, does the work, and returns it to the pool.
That makes sense. In my environment I'm at a higher level of
abstraction - I'm playing with things like user, task, processor,
collaboration, community managers etc. - I'm never looking at
things like eeek - DB connections or sockets! (But just between
you and I, I am watching the DB connection stuff with interest -
one day I will have to introduce you to PSS).
Steve.
Stephen J. McConnell, OSM sarl
digital products for a global economy
http://www.osm.net
mailto:mcconnell@osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 10 January 2002 12:48 pm, Stephen McConnell wrote:
> understand correctly, under Phoenix the proxies etc. are already
> instantiated .. is there a real benefit in delaying a lookup
> invocation ?
I delay lookup in ThreadSafe components that access Pooled ones. Take a
component that accessed the database for example. It is ThreadSafe, but I
don't want to just grab a single connection upon component initialization.
Rather as a data-accessing method is called, it gets a DB connection, does
the work, and returns it to the pool.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal wrote:
> On Thursday 10 January 2002 12:08 pm, Stephen McConnell wrote:
> > No many - generally speaking the work in done in the initialize method
> > but on occasions there is extraction and repacking of components
> > provided by a compooinent that is itself a container. In
> > these cases the component reshuffling code generally throws a
> > Componnet exception along the lines of ...
>
> Ok, sounds like a difference in how our components are authored a
> bit. You're looking up all the other components a component may need
> in the initialization of the component?
Basically paranoid schizophrenic behaviour - paranoid because I'm
validating I have everything I need to do whatever I need to do
(even through I running under DefaultComponentManger - but I known
this ... the code doesn't, I know that could change). Schizophrenic
because its not 100% consistent - I'm actually inclined to relax on
paranoia in favour of late loading. But just for reference, if I
understand correctly, under Phoenix the proxies etc. are already
instantiated .. is there a real benefit in delaying a lookup
invocation ?
Steve.
> I delay loading other components from the CM until actually
> needed in some cases. I have a component that represents an RMI
> connection to my other tier, and I only lookup/release it as
> methods on the "Fetcher" component are called.
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 10 January 2002 12:08 pm, Stephen McConnell wrote:
> No many - generally speaking the work in done in the initialize4 method
> but on occasions there is extraction and repacking of components
> provided by a compooinent that is itself a container. In
> these cases the component reshuffling code generally throws a
> Componnet exception along the lines of ...
Ok, sounds like a difference in how our components are authored a bit. You're
looking up all the other components a component may need in the
initialization of the component?
I delay loading other components from the CM until actually needed in some
cases. I have a component that represents an RMI connection to my other tier,
and I only lookup/release it as methods on the "Fetcher" component are called.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal wrote:
> On Thursday 10 January 2002 10:47 am, Stephen McConnell wrote:
> > > On a side note, I always re-throw any ComponentException's as
> > > RuntimeException's, what do other folk do?
> >
> > I generally rethrow a qualified ComponentException (qualified in
> > that it has meaningful context in the exception message).
>
> Do you wrap them in a RuntimeException or do you have "throws
> ComponentException" on many methods?
No many - generally speaking the work in done in the initialize4 method
but on occasions there is extraction and repacking of components
provided by a compooinent that is itself a container. In
these cases the component reshuffling code generally throws a
Componnet exception along the lines of ...
// inside contextualize
try
{
// do component composition stuff
}
catch( ComponentException e )
{
final String error = "some context relevant message";
throw new ComponentException( error, e );
}
About the only reason for choosing this approach is that
ComponentException is declared and documented - as opposed to
RuntimeExceptions which are less likely to get documented.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 10 January 2002 10:47 am, Stephen McConnell wrote:
> > On a side note, I always re-throw any ComponentException's as
> > RuntimeException's, what do other folk do?
>
> I generally rethrow a qualified ComponentException (qualified in
> that it has meaningful context in the exception message).
Do you wrap them in a RuntimeException or do you have "throws
ComponentException" on many methods?
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal wrote:
> Sent: Thursday, 10 January, 2002 16:38
> To: Avalon Developers List
> Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> On Thursday 10 January 2002 10:26 am, Berin Loritsch wrote:
> > This approach simplifies the use of the Component infrastructure
> > tremendously as we no longer have to have big complex try/catch/finally
> > methods to ensure that we release all components even if they are
> > ThreadSafe.
>
> Are we going to make lookup() not throw a ComponentException
> anymore? If not, (or unless ComponentException extends
> RuntimeException) I don't see how the t/c/f block will go away, as
> you still have to trap the ComponentException.
>
> On a side note, I always re-throw any ComponentException's as
> RuntimeException's, what do other folk do?
I generally rethrow a qualified ComponentException (qualified in
that it has meaningful context in the exception message).
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 10 January 2002 10:26 am, Berin Loritsch wrote:
> This approach simplifies the use of the Component infrastructure
> tremendously as we no longer have to have big complex try/catch/finally
> methods to ensure that we release all components even if they are
> ThreadSafe.
Are we going to make lookup() not throw a ComponentException anymore? If not,
(or unless ComponentException extends RuntimeException) I don't see how the
t/c/f block will go away, as you still have to trap the ComponentException.
On a side note, I always re-throw any ComponentException's as
RuntimeException's, what do other folk do?
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Ah! I think I got it!
The 1st Jedi mind control trick!
=:o)
Thanks Berin and have fun,
Paulo
BTW: from the serious ones, your quote is my favorite.
Very adequate to the present times.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, January 14, 2002 1:03 PM
> To: Avalon Developers List
> Subject: Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> Paulo Gaspar wrote:
>
> > Hi Peter,
>
> >>--------------------------------
> >> These aren't the droids you're
> >> looking for. Move along.
> >>--------------------------------
> >>
> >
> > I don't "get" this one.
> > =;o)
>
>
>
> Hmmm. Perhaps you should watch the original Star Wars again.
> Pay attention to when look and Obi Wan Kenobi arrive at the
> space port on Tatooine.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> Hi Peter,
>>--------------------------------
>> These aren't the droids you're
>> looking for. Move along.
>>--------------------------------
>>
>
> I don't "get" this one.
> =;o)
Hmmm. Perhaps you should watch the original Star Wars again.
Pay attention to when look and Obi Wan Kenobi arrive at the
space port on Tatooine.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Peter,
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Saturday, January 12, 2002 1:53 AM
>
>
> On Sat, 12 Jan 2002 11:50, Paulo Gaspar wrote:
> > > > I sent you the FACTORY code. The component has NO configuration
> > > > points and in this case is not even dependent on the framework.
> > >
> > > Actually it has many configuration points and is not dependent on
> > > framework
> > > ;) Rather than expose one public method to configure service
> you expose N
> > > different setters and each of these setters is another hinge point.
> >
> > No. For configuration I only expose setters in an object that is used
> > ONLY to collect the configuration values. Usually this object is from
> > an inner class - inner to the factory class.
> >
> > That inner object is NOT the component. It is part of the factory.
>
> Time for a code snippet I think ;) How does the configuration
> values get from your "adaptor" object to your real component?
Ok, this hint means that you want _me_ to fetch the snippet from that post
I made ages ago... (It sure took time to find, you lazy b******!)
The snippet is just a bit after the quote and the "Have fun".
Brief legend:
DbFactory - the custom component factory;
CfgBean - the mentioned inner class. Not really a javabean
since I am a lazy b****** (too) and the Configurator
uses field introspection if the "IFieldBasedConfig"
marker interface "marks" this configuration bean;
cfg - The configuration bean, which is an instance of the
CfgBean class;
Connection - The component... yes, a pooled java.sql.Connection!;
m_dbConnPool - The database Connection pool.
Then, the database pool is created by this bit:
// Notice the use of "cfg"... just holding the values
public void customInitialize()
throws Exception
{ IDbConnFactory dbConnFactory =
new DriverManagerConnectionFactory(cfg.driver, cfg.url, cfg.user, cfg.password);
m_dbConnPool = new DbConnectionPool(logger(), dbConnFactory);
m_dbConnPool.setUseBorrowValidation(false);
m_dbConnPool.setUseIdleValidation(false);
m_dbConnPool.setUseReturnValidation(false);
m_dbConnPool.initialize();
}
> --
> Cheers,
>
> Pete
>
> --------------------------------------------
> Sorry, I forgot to take my medication today.
> --------------------------------------------
I noticed!
=;o)
Have fun, the code snippet follows,
Paulo Gaspar
AND NOW... the sample:
// Here goes a simple DB component factory.
// This one is missing a load of parameterization but makes a better
// example. I added some comments just for this mail!
// =:o)
import java.sql.Connection;
import javax.sql.DataSource;
import krankikom.sql.pool.IDbConnFactory;
import krankikom.sql.pool.dbcfactories.DriverManagerConnectionFactory;
import krankikom.sql.pool.PoolingDataSource;
import krankikom.sql.pool.DbConnectionPool;
import krankikom.activity.AbstractLoggableActivity;
import krankikom.log.ILogger;
import krankikom.framework.component.IComponentFactory;
import krankikom.framework.configuration.configurator.*;
public class DbFactory
extends AbstractLoggableActivity
implements IAutoConfigurable, IComponentFactory
// IAutoConfigurable exposes the autoConfigXXX() methods
// that the Configurator will use to "auto-configure" this
// factory.
{
// The IFieldBasedConfig marker tells the Configurator
// to use field introspection instead of the standard
// JavaBean introspection.
// (I am too lazy to find writting setXXX() methods
// interesting for this case.)
public class CfgBean implements IFieldBasedConfig
{
public String name;
public String driver;
public String url;
public String user;
public String password;
// Silly debug helper
public String toString()
{ return getClass().getName()
+ "{ " + fmtCell("*name", name)
+ fmtCell("*driver", driver)
+ fmtCell("*url", url)
+ fmtCell("*user", user)
+ fmtCell("*pwd", "*****")
+ " }";
}
}
public CfgBean cfg = new CfgBean();
private DbConnectionPool m_dbConnPool;
public DbFactory()
{ super();
}
//*** IComponentFactory stuff: ***
public Class createdClass()
{ return java.sql.Connection.class;
}
public boolean isComponentThreadSafe()
{ return false;
}
public Object newInstance()
throws Exception
{ return m_dbConnPool.newDataSource();
}
public void release(Object i_object)
throws Exception
{
if (null != i_object)
((PoolingDataSource)i_object).close();
}
//*** IAutoConfigurable stuff: ***
public Object autoConfigBean()
{ return cfg;
}
public void autoConfigInitialize()
{}
public void autoConfigPropertiesFinalize()
{
// I still want to see a sign that it is working!!! =;o)
System.out.println("CfgBean => " + cfg);
}
public void autoConfigFinalize()
{
}
//*** Life cycle ***
// This customXXX() are called by the lifecycle methods
// at AbstractLoggableActivity which implements the
// Initializable, Disposable, Startable and Logabble
// interfaces with a bunch of checks to make sure I am
// doing things right and also logs on "INFO" level when
// he performs the life cycle methods. UFFFfffff!
public void customInitialize()
throws Exception
{ IDbConnFactory dbConnFactory =
new DriverManagerConnectionFactory(cfg.driver, cfg.url, cfg.user, cfg.password);
m_dbConnPool = new DbConnectionPool(logger(), dbConnFactory);
m_dbConnPool.setUseBorrowValidation(false);
m_dbConnPool.setUseIdleValidation(false);
m_dbConnPool.setUseReturnValidation(false);
m_dbConnPool.initialize();
}
public void customStart()
throws Exception
{ m_dbConnPool.start();
}
public void customStop()
throws Exception
{ m_dbConnPool.stop();
}
public void customDispose()
throws Exception
{ m_dbConnPool.dispose();
}
// Silly debug helpers
protected static String fmtCell(final String i_name, final String i_value)
{ return "[" + i_name + "=" + String.valueOf(i_value) + "]";
}
public String toString()
{ return cfg.toString();
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 11:50, Paulo Gaspar wrote:
> > > I sent you the FACTORY code. The component has NO configuration
> > > points and in this case is not even dependent on the framework.
> >
> > Actually it has many configuration points and is not dependent on
> > framework
> > ;) Rather than expose one public method to configure service you expose N
> > different setters and each of these setters is another hinge point.
>
> No. For configuration I only expose setters in an object that is used
> ONLY to collect the configuration values. Usually this object is from
> an inner class - inner to the factory class.
>
> That inner object is NOT the component. It is part of the factory.
Time for a code snippet I think ;) How does the configuration values get from
your "adaptor" object to your real component?
--
Cheers,
Pete
--------------------------------------------
Sorry, I forgot to take my medication today.
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Peter,
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 11:15 PM
>
> On Sat, 12 Jan 2002 01:56, Paulo Gaspar wrote:
> > Basically, there is one (or more) XML configuration file that
> > configures all Roles and Types which specifies their names,
> > interfaces (role), class factories (type), etc.
> >
> > Then there is one (or more) XML files that configure the sitemap.
> >
> > Note: A "type" is a specific implementation of a "role" and a role
> > is an interface just as in Avalon.
>
> Thats the terminology I tend to use aswell ;)
I did not know you used the "type" bit. Must be one of those obvious
things to do.
=:o)
> > I sent you the FACTORY code. The component has NO configuration
> > points and in this case is not even dependent on the framework.
>
> Actually it has many configuration points and is not dependent on
> framework
> ;) Rather than expose one public method to configure service you expose N
> different setters and each of these setters is another hinge point.
No. For configuration I only expose setters in an object that is used
ONLY to collect the configuration values. Usually this object is from
an inner class - inner to the factory class.
That inner object is NOT the component. It is part of the factory.
> > > However, that is a matter of preference.
> >
> > Actually, from what you say we have the same preferences. I just
> > have to do a better job of explaining my ideas.
>
> No I understand them and I agree that they tend to work better
> when you are
> using Avalon to just create the components rather than manage
> them. As you
> said I tend to use almost the same architecture in Myrmidon.
>
> I started out using ComponentSelector/ECM and friends but found that it
> became too complicated to manage and too highly coupled. However if I was
> writing a webserver/mailserver/imserver/whateverserver I think I
> would still
> use Avalons current mechanisms.
Agreed. Such a server needs mostly a "ServiceManager".
OTOH Myrmidon and my little monster need mostly a ComponentManager.
And adding components must be easy.
I think Cocoon could use both.
> --
> Cheers,
>
> Pete
>
> --------------------------------
> These aren't the droids you're
> looking for. Move along.
> --------------------------------
I don't "get" this one.
=;o)
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 01:56, Paulo Gaspar wrote:
> Basically, there is one (or more) XML configuration file that
> configures all Roles and Types which specifies their names,
> interfaces (role), class factories (type), etc.
>
> Then there is one (or more) XML files that configure the sitemap.
>
> Note: A "type" is a specific implementation of a "role" and a role
> is an interface just as in Avalon.
Thats the terminology I tend to use aswell ;)
> I sent you the FACTORY code. The component has NO configuration
> points and in this case is not even dependent on the framework.
Actually it has many configuration points and is not dependent on framework
;) Rather than expose one public method to configure service you expose N
different setters and each of these setters is another hinge point.
> > However, that is a matter of preference.
>
> Actually, from what you say we have the same preferences. I just
> have to do a better job of explaining my ideas.
No I understand them and I agree that they tend to work better when you are
using Avalon to just create the components rather than manage them. As you
said I tend to use almost the same architecture in Myrmidon.
I started out using ComponentSelector/ECM and friends but found that it
became too complicated to manage and too highly coupled. However if I was
writing a webserver/mailserver/imserver/whateverserver I think I would still
use Avalons current mechanisms.
--
Cheers,
Pete
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin, answer inline,
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, January 11, 2002 3:06 PM
>
> Paulo Gaspar wrote:
>
> ...
> >
> > There is so much in a word....
> >
> > For me an URL is a component. Really! But...
>
>
>
> That's the problem with the word Component. It is overused so many
> times, and noone defines it very well. Maybe I should write a book ;)
Yeah, that is why I like better the "Service" expression that Peter
just used.
> > ...
> >
> > I mean, my "Sitemap" does a lot of the same that Cocoon's
> Sitemap does and
> > I just use my standard ComponentManager and Configurator
> functionality for
> > that. They have to do a lot more manually I think.
>
>
> Yea. I was looking at your code snippet, and I finally have a couple of
> comments. First, I was really looking for how a Client component uses the
> ComponentManager you have, ...
Do you know Cocoon's Environment, that holds the request, response and
object model objects + any other stuff used to process a request?
Well, that one also references the ComponentManager but only exposes the
lookup and release methods, which are basically implemented like this:
public class WebEnvironment
{
private ComponentManager m_componentManager;
...
public Object lookup(Class i_role, String i_name)
{
return m_componentManager.lookup(this, i_role, i_name);
}
public Object release(Object i_component)
{
return m_componentManager.release(i_component);
}
}
So, the environment object is used as the "token".
The above "release()" method was never used yet since components always
have some other way of being released. For instance, when a pooled
Connection is close that returns it to the pool. The pool has a
notification mechanism that signals the custom factory that the
Connection was released and this one calls ComponentManager.release().
Notice that:
- My Database Connection Pool does not depend on the framework. Only
its factory does;
- The Connection is actually returned to the pool before being
"released" by the component manager. This just removes from the
tracking list in this case, avoiding that the CM tries to release
the Connection again after the request is processed...
After the request is processed all components not yet released are
(released) by calling:
m_componentManager.releaseAll(webEnv);
> ... and how the ComponentManager itself is set up.
Well, the syntax is not so important here, but it is very similar to
the mechanisms used by Cocoon and Avalon.
Basically, there is one (or more) XML configuration file that
configures all Roles and Types which specifies their names,
interfaces (role), class factories (type), etc.
Then there is one (or more) XML files that configure the sitemap.
Note: A "type" is a specific implementation of a "role" and a role
is an interface just as in Avalon.
What details are you interested on?
> Second, your system is based on the JavaBeans approach, and features an
> Active configuration system. By that I mean that you expose all sorts
> of configuration points via setters and getters as opposed to reading
> a passive configuration object and configuring the component based on
> that.
>
> I prefer the passive configuration system that Avalon uses due to the fact
> that I have tight control over what settings are applied and when.
Believe me, I have no less control here.
Remember that I just put values converted to the right types on the
configuration beans, but ONLY after that do I use those values to do
something.
In the primary version I sent you there was no validation BUT it is
not like that in the final version of that component (which, however,
is too confusing).
During type conversion, a bad format (e.g.: a number expressed as
"XPTO") will trigger an Exception and stop the configuration.
After the values are at the bean, I can check if they make sense and
I can check if they were filled (if not they are null).
For most components it is not necessary to do any checking:
- Thread safe components are immediately built and their constructor
usually checks if the parameters are valid;
- Same with Pools!
> Secondly,
> I prefer it due to the fact that the interface of the Component
> isn't muddied
> by what amounts to Configuration points.
Hey, you got it wrong.
I sent you the FACTORY code. The component has NO configuration
points and in this case is not even dependent on the framework.
> However, that is a matter of preference.
Actually, from what you say we have the same preferences. I just
have to do a better job of explaining my ideas.
Or, probably, we just have to keep talking. There are many parts
involved and it is hard to transmit it all that was built and
tried and transformed during several months in just a couple of
days.
Hey, I am still learning why some things in Avalon are as they
are. Very often I end up learning that something I though was
non-sense is actually very useful.
> >>token == transaction of components ? Nice idea. SO for each
> >>"symphony" you
> >>are guarenteed that you release your components and so forth
> >>right? This is
> >>more aimed at a request based architecture rather than
> persistent service
> >>based architecture ?
> >>
> >
> > Yes, you understood it well.
> >
> > Even in a persistent Architecture it would help to ensure that all
> > resources are released when you shut it down, but for such architecture
> > you would probably not need the "token".
> >
> > However, most persistent Architectures have some bit where they could
> > use this token thing:
> > - Imagine James providing access to (my flavor of) components for a
> > mailet and ensuring all resources used for a request would be
> > closed;
> > - Imagine webapp reload on a Servlet Container. With Servlet
> > containers providing things like user validation via database and
> > some J2EE services, you want to clean up that kind of stuff when
> > you reload a webapp;
> > - Same thing for mailet reload?
>
>
> Actually, the Token approach would work quite well for Cocoon who wants
> the ability to lookup a component to use for the life of a request,
> and release them all when the request is over.
=:o)
Together with the "active configuration" and the Converter, its my
favorite new feature.
But the "active configuration" and Converter ideas I got from Peter and
his work at Ant-Myrmidon.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> Hi Peter, answer inline:
>
>
>>-----Original Message-----
>>From: Peter Donald [mailto:peter@apache.org]
>>Sent: Friday, January 11, 2002 7:56 AM
>>
>>
>>On Fri, 11 Jan 2002 04:55, Paulo Gaspar wrote:
>>
>>>>At the moment, the CM does one thing and does it very well -
>>>>handles *components*.
>>>>
>>>Now, just tell me how specific (not-do-general) the "component"
>>>concept is to you?
>>>=;o)
>>>
>>I agree with Leo that "component" concept is definetly not meant to be a
>>generic object description. You should not be able to put in raw
>>objects like
>>ClassLoader, Datagrams, URLs and so forth - they are not components.
>>
>
> There is so much in a word....
>
> For me an URL is a component. Really! But...
That's the problem with the word Component. It is overused so many
times, and noone defines it very well. Maybe I should write a book ;)
>>It may be clearer to use the term ServiceManager rather than
>>ComponentManager
>>because that has a easier to grok description of what a CM is
>>meant to do.
>>For sharing of generic resources that are not services but data
>>then Context
>>is probably the place for it.
>>
>
> ...this makes it much less confusing. =:o)
>
> Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 to have a
> brand new ComponentManager which could provide the core functionality for
> the ServiceManager (now called ComponentManager).
>
> So, Avalon would get BOTH a Service Manager and a Component Manager. This
> would make the framework quite a bit more generic and I think it would be
> of better use for projects like Ant-Myrmidon and Cocoon.
>
> I mean, my "Sitemap" does a lot of the same that Cocoon's Sitemap does and
> I just use my standard ComponentManager and Configurator functionality for
> that. They have to do a lot more manually I think.
Yea. I was looking at your code snippet, and I finally have a couple of
comments. First, I was really looking for how a Client component uses the
ComponentManager you have, and how the ComponentManager itself is set up.
Second, your system is based on the JavaBeans approach, and features an
Active configuration system. By that I mean that you expose all sorts
of configuration points via setters and getters as opposed to reading
a passive configuration object and configuring the component based on
that.
I prefer the passive configuration system that Avalon uses due to the fact
that I have tight control over what settings are applied and when. Secondly,
I prefer it due to the fact that the interface of the Component isn't muddied
by what amounts to Configuration points.
However, that is a matter of preference.
>>token == transaction of components ? Nice idea. SO for each
>>"symphony" you
>>are guarenteed that you release your components and so forth
>>right? This is
>>more aimed at a request based architecture rather than persistent service
>>based architecture ?
>>
>
> Yes, you understood it well.
>
> Even in a persistent Architecture it would help to ensure that all
> resources are released when you shut it down, but for such architecture
> you would probably not need the "token".
>
> However, most persistent Architectures have some bit where they could
> use this token thing:
> - Imagine James providing access to (my flavor of) components for a
> mailet and ensuring all resources used for a request would be
> closed;
> - Imagine webapp reload on a Servlet Container. With Servlet
> containers providing things like user validation via database and
> some J2EE services, you want to clean up that kind of stuff when
> you reload a webapp;
> - Same thing for mailet reload?
Actually, the Token approach would work quite well for Cocoon who wants
the ability to lookup a component to use for the life of a request,
and release them all when the request is over.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> Hi Berin,
>
>>BTW, What you call a service, we call a Component.
>>
>
>
> ARGH! Again!
> =:o)
>
> So, what is a Service and what is a Component?
> Is it written somewhere?
Actually, in a few places. There are even a few books out on Component Oriented
Programming.
The basic criterea is that a Component is defined by it's interface,
which provides a black-box view of the Component. Furthermore, it
is also defined by the contracts that the interface defines.
For example, the interface here:
/** Provides object storage */
interface Store
{
/** returns a lookup key for the object */
int store(Object o);
/** returns an object for the lookup key */
Object retrieve(int key);
}
Any Component that implements this interface only has three contracts:
1) It must store objects in some manner
2) It must generate a key for a stored object
3) It must be able to retrieve an object based on that key
What the interface does not define follows:
1) It does not determine whether it is permanent or temporary storage
2) It does not define if the key is no longer stored after the first retrieval
3) It does not define the machanism for storage
It is important to note that the interface, its explicit contracts, and
just as importantly what it does not define all make up a Component.
Components are best used to provide services of some sort. That is why
the URL (an Object) is not a Component.
This is true whether you are using COM, KOM, CORBA, Bonobo, SOM, Component
Pascal, Java, or a partridge and a pear tree.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
>
> So, what is a Service and what is a Component?
Start by reading http://jakarta.apache.org/avalon/developing/decomposing.html
if you have not done so yet. It has a discussion on what a component is and
isn't.
Just like you, I tended to make everything a Component when I started with
Avalon (getting there from an EJB background).
Rule of thumb: A Component is not a domain object.
You seem to have a COM / C++
background - have you worked with DirectX? The IDirectDraw interface is a
Component. The IDirectDrawSurface isn't. (As I see it, anyway.)
If you have EJB experience, I'd say a Component is roughly equal to a
Stateless Session Bean. It is *not* an Entity Bean.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin,
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, January 14, 2002 1:09 PM
>
>
> Paulo Gaspar wrote:
>
> > And Hi again,
> > =:o)
> >>Well it comes down to what is intended to be pulled out from
> the manager.
> >>A4CM is intended to be used to pull out services while
> A4Context/A5CM is
> >>intended to pull out data relevent to specific
> >>environment/context/whatever.
> >>
> >
> > Nops. I often pull very life components, like DB connections or
> SQL queries
> > (we like to put SQL query templates in XML). But I also get strings and
> > static lists of records.
>
>
>
> For the record, DB Connection Objects && SQL Queries != Component.
> The DataSource interface and any implementation can be construed as a
> Component, because the interface is intended as an access point to data
> (The Connection object).
I still do not get the criteria that says that something is a Component
or is Service.
> Components should strive to have a simple interface that only
> exposes enough
> detail for clients to do their job.
Of course. I am an adept of minimal interfaces too.
> >>In A4CM the string is required to indicate a ROle/interface while in
> >>A4Context the key is an object. (In hindsight a free form
> string may have
> >>been better).
> >>
> >
> > I thought so at first but I find it very practical to do things
> like this:
> >
> > IConverter cvt = ctx.get(IConverter.class);
> >
> > This gets the type conversion "service" from my context. See? I use the
> > context as a ServiceManager!
> > =;o)
> >
> > I still found no problems with this approach.
>
>
>
> BTW, What you call a service, we call a Component.
ARGH! Again!
=:o)
So, what is a Service and what is a Component?
Is it written somewhere?
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
Yeah!
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> And Hi again,
> =:o)
>>Well it comes down to what is intended to be pulled out from the manager.
>>A4CM is intended to be used to pull out services while A4Context/A5CM is
>>intended to pull out data relevent to specific
>>environment/context/whatever.
>>
>
> Nops. I often pull very life components, like DB connections or SQL queries
> (we like to put SQL query templates in XML). But I also get strings and
> static lists of records.
For the record, DB Connection Objects && SQL Queries != Component.
The DataSource interface and any implementation can be construed as a
Component, because the interface is intended as an access point to data
(The Connection object).
Components should strive to have a simple interface that only exposes enough
detail for clients to do their job.
>>In A4CM the string is required to indicate a ROle/interface while in
>>A4Context the key is an object. (In hindsight a free form string may have
>>been better).
>>
>
> I thought so at first but I find it very practical to do things like this:
>
> IConverter cvt = ctx.get(IConverter.class);
>
> This gets the type conversion "service" from my context. See? I use the
> context as a ServiceManager!
> =;o)
>
> I still found no problems with this approach.
BTW, What you call a service, we call a Component.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
And Hi again,
=:o)
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 11:08 PM
>
>
> On Sat, 12 Jan 2002 02:04, Paulo Gaspar wrote:
> > > What would be the difference between an Avalon4 Context and an Avalon5
> > > ComponentManager ?
> >
> > Let me answer you with a question:
> > What is the difference between an Avalon 4 Context and an Avalon 4
> > ComponentManager?
> >
> >
> > The only difference between and Avalon 4 ComponentManager and an
> > Avalon 5 ComponentManager is the way you index components - i.e.,
> > the format of the lookup key.
>
> Well it comes down to what is intended to be pulled out from the manager.
> A4CM is intended to be used to pull out services while A4Context/A5CM is
> intended to pull out data relevent to specific
> environment/context/whatever.
Nops. I often pull very life components, like DB connections or SQL queries
(we like to put SQL query templates in XML). But I also get strings and
static lists of records.
> In A4CM the string is required to indicate a ROle/interface while in
> A4Context the key is an object. (In hindsight a free form string may have
> been better).
I thought so at first but I find it very practical to do things like this:
IConverter cvt = ctx.get(IConverter.class);
This gets the type conversion "service" from my context. See? I use the
context as a ServiceManager!
=;o)
I still found no problems with this approach.
> A4CM = Service directory + specified key format
> A4Context = Data directory + unspecified object format
Well, at least we agree that a Context is a data directory... although
it can be a Directory service too.
=:o)
> --
> Cheers,
>
> Pete
>
> -------------------------
> All things considered,
> insanity may be the only
> reasonable alternative.
> -------------------------
Just my thoughts the other day messing up with my framework...
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 02:04, Paulo Gaspar wrote:
> > What would be the difference between an Avalon4 Context and an Avalon5
> > ComponentManager ?
>
> Let me answer you with a question:
> What is the difference between an Avalon 4 Context and an Avalon 4
> ComponentManager?
>
>
> The only difference between and Avalon 4 ComponentManager and an
> Avalon 5 ComponentManager is the way you index components - i.e.,
> the format of the lookup key.
Well it comes down to what is intended to be pulled out from the manager.
A4CM is intended to be used to pull out services while A4Context/A5CM is
intended to pull out data relevent to specific environment/context/whatever.
In A4CM the string is required to indicate a ROle/interface while in
A4Context the key is an object. (In hindsight a free form string may have
been better).
A4CM = Service directory + specified key format
A4Context = Data directory + unspecified object format
--
Cheers,
Pete
-------------------------
All things considered,
insanity may be the only
reasonable alternative.
-------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Peter, answer inline as usual:
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 3:01 PM
>
>
> On Sat, 12 Jan 2002 00:54, Paulo Gaspar wrote:
> > > It may be clearer to use the term ServiceManager rather than
> > > ComponentManager
> > > because that has a easier to grok description of what a CM is
> > > meant to do.
> > > For sharing of generic resources that are not services but data
> > > then Context
> > > is probably the place for it.
> >
> > ...this makes it much less confusing. =:o)
>
> kool.
But not the Context bit!
=;o)
> > Ok, what I am proposing is for Avalon (Framework + Excalibur) 5
> to have a
> > brand new ComponentManager which could provide the core
> functionality for
> > the ServiceManager (now called ComponentManager).
> >
> > So, Avalon would get BOTH a Service Manager and a Component
> Manager. This
> > would make the framework quite a bit more generic and I think
> it would be
> > of better use for projects like Ant-Myrmidon and Cocoon.
>
> What would be the difference between an Avalon4 Context and an Avalon5
> ComponentManager ?
Let me answer you with a question:
What is the difference between an Avalon 4 Context and an Avalon 4
ComponentManager?
The only difference between and Avalon 4 ComponentManager and an
Avalon 5 ComponentManager is the way you index components - i.e.,
the format of the lookup key.
> > I mean, my "Sitemap" does a lot of the same that Cocoon's
> Sitemap does and
> > I just use my standard ComponentManager and Configurator
> functionality for
> > that. They have to do a lot more manually I think.
>
> I think Context is meant to do that. Essentially Avalon4's
> Context serves 4
> "styles" of context. It actually has similarities to context as
> defined in
> linguistic theory ;)
>
> 1. World Context / Per-Application context: So this describes application
> wide settings. An example may be the working directory of the application.
>
> 2. Person Context / Per-Component context: This contains context
> information
> specific to the component. An example may be the name of the component.
>
> 3. Conversation Context / Per-Session context: This contains context
> information specific to the component. An example may be the IP
> address of
> person who you are talking to.
>
> 4. Speach Act Context / Per-Request context: This contains
> information about
> a specific request in component. Example may include the
> parameter submitted
> to a particular web form or whatever.
>
> When we implement this (1) and (2) are generally merged into one
> interface.
> For instance in pheonix we have a block context that among other
> things has
> two methods. One is getHomeDirectory() and that belongs to (1) while the
> other is getName() which belongs to (2).
>
> (4) is usually passed into a service() style method as
> parameters. So you may
> have something like
I use Contexts these ways too.
> void doMagic( int param1, int param2, Context otherParamsInHere );
>
> When (3) is needed in the system it is usually also passed into
> the "service"
> method or alternatively it is made available via the context
> representing (4).
>
> My memory is sketchy but I believe C2 used an Environment object that was
> basically the Per-Request parameters and Per-Session stuff.
> Though I don't think it extended Context or anything like that.
No, but I think it holds a Context. I am not sure. (I know mine does.)
> hmm .. maybe I should should condense/clean this explanation and
> place it in
> the javadocs ...
YOU SURE SHOULD!
=:o)
> --
> Cheers,
>
> Pete
>
> *------------------------------------------------*
> | You can't wake a person who is pretending |
> | to be asleep. -Navajo Proverb. |
> *------------------------------------------------*
LOL!
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 00:54, Paulo Gaspar wrote:
> > It may be clearer to use the term ServiceManager rather than
> > ComponentManager
> > because that has a easier to grok description of what a CM is
> > meant to do.
> > For sharing of generic resources that are not services but data
> > then Context
> > is probably the place for it.
>
> ...this makes it much less confusing. =:o)
kool.
> Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 to have a
> brand new ComponentManager which could provide the core functionality for
> the ServiceManager (now called ComponentManager).
>
> So, Avalon would get BOTH a Service Manager and a Component Manager. This
> would make the framework quite a bit more generic and I think it would be
> of better use for projects like Ant-Myrmidon and Cocoon.
What would be the difference between an Avalon4 Context and an Avalon5
ComponentManager ?
> I mean, my "Sitemap" does a lot of the same that Cocoon's Sitemap does and
> I just use my standard ComponentManager and Configurator functionality for
> that. They have to do a lot more manually I think.
I think Context is meant to do that. Essentially Avalon4's Context serves 4
"styles" of context. It actually has similarities to context as defined in
linguistic theory ;)
1. World Context / Per-Application context: So this describes application
wide settings. An example may be the working directory of the application.
2. Person Context / Per-Component context: This contains context information
specific to the component. An example may be the name of the component.
3. Conversation Context / Per-Session context: This contains context
information specific to the component. An example may be the IP address of
person who you are talking to.
4. Speach Act Context / Per-Request context: This contains information about
a specific request in component. Example may include the parameter submitted
to a particular web form or whatever.
When we implement this (1) and (2) are generally merged into one interface.
For instance in pheonix we have a block context that among other things has
two methods. One is getHomeDirectory() and that belongs to (1) while the
other is getName() which belongs to (2).
(4) is usually passed into a service() style method as parameters. So you may
have something like
void doMagic( int param1, int param2, Context otherParamsInHere );
When (3) is needed in the system it is usually also passed into the "service"
method or alternatively it is made available via the context representing (4).
My memory is sketchy but I believe C2 used an Environment object that was
basically the Per-Request parameters and Per-Session stuff. Though I don't
think it extended Context or anything like that.
hmm .. maybe I should should condense/clean this explanation and place it in
the javadocs ...
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Peter, answer inline:
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Friday, January 11, 2002 7:56 AM
>
>
> On Fri, 11 Jan 2002 04:55, Paulo Gaspar wrote:
> > > At the moment, the CM does one thing and does it very well -
> > > handles *components*.
> >
> > Now, just tell me how specific (not-do-general) the "component"
> > concept is to you?
> > =;o)
>
> I agree with Leo that "component" concept is definetly not meant to be a
> generic object description. You should not be able to put in raw
> objects like
> ClassLoader, Datagrams, URLs and so forth - they are not components.
There is so much in a word....
For me an URL is a component. Really! But...
> It may be clearer to use the term ServiceManager rather than
> ComponentManager
> because that has a easier to grok description of what a CM is
> meant to do.
> For sharing of generic resources that are not services but data
> then Context
> is probably the place for it.
...this makes it much less confusing. =:o)
Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 to have a
brand new ComponentManager which could provide the core functionality for
the ServiceManager (now called ComponentManager).
So, Avalon would get BOTH a Service Manager and a Component Manager. This
would make the framework quite a bit more generic and I think it would be
of better use for projects like Ant-Myrmidon and Cocoon.
I mean, my "Sitemap" does a lot of the same that Cocoon's Sitemap does and
I just use my standard ComponentManager and Configurator functionality for
that. They have to do a lot more manually I think.
And then, this would be interesting for most servers. I mean, I could
develop "mailets" with my xml-configured-components + scripting
architecture.
=:o)
> > I prefer the way I solved the problem - the "token" way. You just pass
> > some token that identifies your task and you can release all components
> > in a single step. This "token" can just be the current thread, like
> > this:
> >
> > Object myToken = Thread.currentThread();
> >
> > try
> > {
> > MyClass1 cmp1 = (MyClass1)cm.lookup(myToken, "myRole1",
> "myHint1");
> > MyClass2 cmp2 = (MyClass2)cm.lookup(myToken, "myRole2",
> "myHint2");
> > MyClass3 cmp3 = (MyClass3)cm.lookup(myToken, "myRole3",
> "myHint3");
> >
> > // And now lets do a lot of stuff...
> >
> > ...
> >
> > // ...a lot of stuff done.
> > }
> > finally
> > {
> > cm.releaseAll(myToken);
> > }
>
> token == transaction of components ? Nice idea. SO for each
> "symphony" you
> are guarenteed that you release your components and so forth
> right? This is
> more aimed at a request based architecture rather than persistent service
> based architecture ?
Yes, you understood it well.
Even in a persistent Architecture it would help to ensure that all
resources are released when you shut it down, but for such architecture
you would probably not need the "token".
However, most persistent Architectures have some bit where they could
use this token thing:
- Imagine James providing access to (my flavor of) components for a
mailet and ensuring all resources used for a request would be
closed;
- Imagine webapp reload on a Servlet Container. With Servlet
containers providing things like user validation via database and
some J2EE services, you want to clean up that kind of stuff when
you reload a webapp;
- Same thing for mailet reload?
> --
> Cheers,
>
> Pete
>
> ----------------------------------------------
> Money is how people with no talent keep score.
> ----------------------------------------------
Sometimes it must be fun not to have talent in that way!
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Fri, 11 Jan 2002 04:55, Paulo Gaspar wrote:
> > At the moment, the CM does one thing and does it very well -
> > handles *components*.
>
> Now, just tell me how specific (not-do-general) the "component"
> concept is to you?
> =;o)
I agree with Leo that "component" concept is definetly not meant to be a
generic object description. You should not be able to put in raw objects like
ClassLoader, Datagrams, URLs and so forth - they are not components.
It may be clearer to use the term ServiceManager rather than ComponentManager
because that has a easier to grok description of what a CM is meant to do.
For sharing of generic resources that are not services but data then Context
is probably the place for it.
> I prefer the way I solved the problem - the "token" way. You just pass
> some token that identifies your task and you can release all components
> in a single step. This "token" can just be the current thread, like
> this:
>
> Object myToken = Thread.currentThread();
>
> try
> {
> MyClass1 cmp1 = (MyClass1)cm.lookup(myToken, "myRole1", "myHint1");
> MyClass2 cmp2 = (MyClass2)cm.lookup(myToken, "myRole2", "myHint2");
> MyClass3 cmp3 = (MyClass3)cm.lookup(myToken, "myRole3", "myHint3");
>
> // And now lets do a lot of stuff...
>
> ...
>
> // ...a lot of stuff done.
> }
> finally
> {
> cm.releaseAll(myToken);
> }
token == transaction of components ? Nice idea. SO for each "symphony" you
are guarenteed that you release your components and so forth right? This is
more aimed at a request based architecture rather than persistent service
based architecture ?
--
Cheers,
Pete
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Leo, answer inline:
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, January 10, 2002 4:58 PM
>
> ...
> >
> > Leo Sutic wrote:
> >
> > That is one implementation. However, the contract of a ComponentManager
> > is to match a lookup request to a Component--nothing more.
>
> Yes, but there must be some predictability here. The returned object
> must be castable to the asked-for interface, and there must be some
> standard way of configuring a component manager so that the configurator
> can with reasonable confidence say that "this will map the lookup
> request X to component Y."
>
> You may want the CM to be a very general thing, to be able to
> handle lookups
> of not just components, but of everything under the sun, but the
> less you specify
> about its behavior the less useful it gets.
>
> At the moment, the CM does one thing and does it very well -
> handles *components*.
Now, just tell me how specific (not-do-general) the "component"
concept is to you?
=;o)
> If you need a general lookup class, try an Object DB.
Overkill, does not do all those nice checkings like the ECM, etc.
=:o)
Ok, I argumented about this one in a previous post.
> > If a Servlet that uses Avalon wants to interpret the Context
> for the URI,
> > and other properties, it is not up to us to limit that
> approach. In fact,
> > just such an approach would be very powerful.
>
> But how would that be done if not via a ComponentSelector?
>
> ...
>
> Not really - whatever logic you want to use to interpret the Context in
> the CM, I would move to a default ComponentSelector and then use
> as above.
I see the ComponentSelector as an "implementation detail". I would
prefer a more generic way of expressing the "indexing" strategy
used to map key to component.
> > ...
> >
> > This approach simplifies the use of the Component infrastructure
> > tremendously as we no
> > longer have to have big complex try/catch/finally methods to
> > ensure that we release
> > all components even if they are ThreadSafe.
>
> Then you make the user of a component have to keep track of whether
> a component is thread safe or not, which is bad. Now, I can treat all
> components as being just components, irrespective of whether they are
> pooled or single threaded or threadsafe. While you will save 3-4 lines
> of code, I think this will result in a massive increase in coupling.
>
> What if a previously pooled component by some magical way becomes
> thread safe? With your proposal, that would be a backwards-incompatible
> change.
I also do not like this method. Again, it makes it harder to use 3rd
party components, even because of a possible name colision with the
dispose() method.
Besides, as I mentioned before, it is a completelly different contract
and keeping the Component name raises some confusion.
I prefer the way I solved the problem - the "token" way. You just pass
some token that identifies your task and you can release all components
in a single step. This "token" can just be the current thread, like
this:
Object myToken = Thread.currentThread();
try
{
MyClass1 cmp1 = (MyClass1)cm.lookup(myToken, "myRole1", "myHint1");
MyClass2 cmp2 = (MyClass2)cm.lookup(myToken, "myRole2", "myHint2");
MyClass3 cmp3 = (MyClass3)cm.lookup(myToken, "myRole3", "myHint3");
// And now lets do a lot of stuff...
...
// ...a lot of stuff done.
}
finally
{
cm.releaseAll(myToken);
}
My mechanism only keeps track of components identified as
SingleThreaded, which includes the pooled ones, which are
identified by their factory as I described before in this
thread.
> > Also by enforcing the lifestyle of the Components like this, we
> > encourage threadsafety
> > as a system goal--which does increase the efficiency of using
> > system resources.
> >
> > Of course, we could address the whole issue by returning to the
> > concept that all Components
> > must be ThreadSafe
>
> No. Then we would end up with all components being factories.
I found it fine all components HAVING fatories, which as I
described before was NOT extra work.
Besides that, how can one make a pooled DB Connection thread safe??
>
> > , and in the cases of a Transformer that
> > extends ContentHandler it would
> > have to be changed like this:
> >
> > interface Transformer
> > {
> > XMLFilter getFilter(Context context, String source, Parameters);
> > }
> >
> > That way, the part of the interface that precluded the
> > Transformer from being ThreadSafe
> > returns a unique instance to be used in the Pipeline.
> >
> > In the end, this may be the best option in all,
>
> Not by far.
We will get there.
=:o)
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
>
> That is one implementation. However, the contract of a ComponentManager
> is to match a lookup request to a Component--nothing more.
Yes, but there must be some predictability here. The returned object
must be castable to the asked-for interface, and there must be some
standard way of configuring a component manager so that the configurator
can with reasonable confidence say that "this will map the lookup request X
to component Y."
You may want the CM to be a very general thing, to be able to handle lookups
of not just components, but of everything under the sun, but the less you specify
about its behavior the less useful it gets.
At the moment, the CM does one thing and does it very well - handles *components*.
If you need a general lookup class, try an Object DB.
> If a Servlet that uses Avalon wants to interpret the Context for the URI,
> and other properties, it is not up to us to limit that approach. In fact,
> just such an approach would be very powerful.
But how would that be done if not via a ComponentSelector?
> The ComponentManager is free to have a default component for any specific
> role.
>
> > Since the Context may have, for example, HttpRequests, I
> > do not want to let the CM interpret the contents of it.
>
>
> That is up to you, but I think it might be an artificial limitation to the
> ComponentManager in general.
Not really - whatever logic you want to use to interpret the Context in
the CM, I would move to a default ComponentSelector and then use as above.
> > BTW, do we dump the Component interface?
>
>
> I think that is the general consensus. However I do have one more use for
> it:
>
> If we move the release() method from ComponentManager, and place it in the
> Component interface, then Components that require releasing because they
> are pooled have a mechanism to do so. That policy should be
> decided by the
> work interface. For example: a component that extends
> ContentHandler cannot
> be threadsafe, so it would implement the Component interface--but
> a component
> that does not need to be pooled by virtue of the work interface would not
> implement the Component interface.
>
> This addresses the current need for the SingleThreaded and
> Threadsafe marker
> interfaces. In Cocoon parlance, the usage would be something like this:
>
> DataSourceComponent datasource =
> (DataSourceComponent) manager.lookup(
> DataSourceComponent.ROLE, this.context );
> Generator generator = (Generator) manager.lookup( Generator.ROLE,
> this.context );
>
> // .... use both generator and DataSourceComponent ...
> // NOTE: Generator extends the Component interface and
> DataSourceComponent does not
>
> generator.release();
>
>
> The enforcement would be that all Components are assumed to be
> ThreadSafe in implementation,
> with the exception of those whose interfaces will not allow it.
> In those cases, the
> Components will be pooled, and extend the Component interface
> that will look like this:
>
> interface Component
> {
> void release();
> }
>
>
> This approach simplifies the use of the Component infrastructure
> tremendously as we no
> longer have to have big complex try/catch/finally methods to
> ensure that we release
> all components even if they are ThreadSafe.
Then you make the user of a component have to keep track of whether
a component is thread safe or not, which is bad. Now, I can treat all
components as being just components, irrespective of whether they are
pooled or single threaded or threadsafe. While you will save 3-4 lines
of code, I think this will result in a massive increase in coupling.
What if a previously pooled component by some magical way becomes
thread safe? With your proposal, that would be a backwards-incompatible
change.
> Also by enforcing the lifestyle of the Components like this, we
> encourage threadsafety
> as a system goal--which does increase the efficiency of using
> system resources.
>
> Of course, we could address the whole issue by returning to the
> concept that all Components
> must be ThreadSafe
No. Then we would end up with all components being factories.
> , and in the cases of a Transformer that
> extends ContentHandler it would
> have to be changed like this:
>
> interface Transformer
> {
> XMLFilter getFilter(Context context, String source, Parameters);
> }
>
> That way, the part of the interface that precluded the
> Transformer from being ThreadSafe
> returns a unique instance to be used in the Pipeline.
>
> In the end, this may be the best option in all,
Not by far.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline:
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, January 10, 2002 4:27 PM
>
>
> Leo Sutic wrote:
>
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> ...
>
> That is one implementation. However, the contract of a ComponentManager
> is to match a lookup request to a Component--nothing more.
That is exactly like the contract for a Map... which uses an Object key!
=;o)
> ...
>
> The ComponentManager is free to have a default component for any specific
> role.
And even to have its own component "indexing"/mapping strategy.
> > Since the Context may have, for example, HttpRequests, I
> > do not want to let the CM interpret the contents of it.
>
> That is up to you, but I think it might be an artificial limitation to the
> ComponentManager in general.
Me too. It is just another component "indexing"/mapping strategy.
> > BTW, do we dump the Component interface?
>
>
> I think that is the general consensus. However I do have one more use for
> it:
>
> If we move the release() method from ComponentManager, and place it in the
> Component interface, then Components that require releasing because they
> are pooled have a mechanism to do so. That policy should be
> decided by the
> work interface. For example: a component that extends
> ContentHandler cannot
> be threadsafe, so it would implement the Component interface--but
> a component
> that does not need to be pooled by virtue of the work interface would not
> implement the Component interface.
>
> This addresses the current need for the SingleThreaded and
> Threadsafe marker
> interfaces. In Cocoon parlance, the usage would be something like this:
>
> DataSourceComponent datasource =
> (DataSourceComponent) manager.lookup(
> DataSourceComponent.ROLE, this.context );
> Generator generator = (Generator) manager.lookup( Generator.ROLE,
> this.context );
>
> // .... use both generator and DataSourceComponent ...
> // NOTE: Generator extends the Component interface and
> DataSourceComponent does not
>
> generator.release();
>
>
> The enforcement would be that all Components are assumed to be
> ThreadSafe in implementation,
> with the exception of those whose interfaces will not allow it.
> In those cases, the
> Components will be pooled, and extend the Component interface
> that will look like this:
>
> interface Component
> {
> void release();
> }
>
>
> This approach simplifies the use of the Component infrastructure
> tremendously as we no
> longer have to have big complex try/catch/finally methods to
> ensure that we release
> all components even if they are ThreadSafe.
>
> Also by enforcing the lifestyle of the Components like this, we
> encourage threadsafety
> as a system goal--which does increase the efficiency of using
> system resources.
>
> Of course, we could address the whole issue by returning to the
> concept that all Components
> must be ThreadSafe, and in the cases of a Transformer that
> extends ContentHandler it would
> have to be changed like this:
>
> interface Transformer
> {
> XMLFilter getFilter(Context context, String source, Parameters);
> }
>
> That way, the part of the interface that precluded the
> Transformer from being ThreadSafe
> returns a unique instance to be used in the Pipeline.
>
> In the end, this may be the best option in all, and we would have
> to beef up the Developing
> With Avalon paper even more to teach these principles.
That is a new contract. It would be confusing to use the same name.
But worse, then you make it harder again to use third party tools.
I think that a SingleThreaded interface marker can still have its
use if you do not want to put this kind of info in a implementation
as I do and, instead, use a generic mechanism that checks for such
marker. I think, however, that this is kind of an "implementation
detail".
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>interface ComponentManager
>>{
>> Object lookup( String role );
>> Object lookup( String role, Context hint );
>>}
>>
>
> Berin,
>
> the snippet above, I think, would be ideal. I also think that
> the lookup(String, Context) method should work like this:
>
> public Object lookup( String role, Context hint )
> {
> Object component = lookup (role);
>
> if ( component instanceof ComponentSelector)
> {
> return component.lookup (hint);
> }
> else
> {
> return component;
> }
> }
That is one implementation. However, the contract of a ComponentManager
is to match a lookup request to a Component--nothing more.
If a Servlet that uses Avalon wants to interpret the Context for the URI,
and other properties, it is not up to us to limit that approach. In fact,
just such an approach would be very powerful.
The ComponentManager is free to have a default component for any specific
role.
> Since the Context may have, for example, HttpRequests, I
> do not want to let the CM interpret the contents of it.
That is up to you, but I think it might be an artificial limitation to the
ComponentManager in general.
> BTW, do we dump the Component interface?
I think that is the general consensus. However I do have one more use for
it:
If we move the release() method from ComponentManager, and place it in the
Component interface, then Components that require releasing because they
are pooled have a mechanism to do so. That policy should be decided by the
work interface. For example: a component that extends ContentHandler cannot
be threadsafe, so it would implement the Component interface--but a component
that does not need to be pooled by virtue of the work interface would not
implement the Component interface.
This addresses the current need for the SingleThreaded and Threadsafe marker
interfaces. In Cocoon parlance, the usage would be something like this:
DataSourceComponent datasource =
(DataSourceComponent) manager.lookup( DataSourceComponent.ROLE, this.context );
Generator generator = (Generator) manager.lookup( Generator.ROLE, this.context );
// .... use both generator and DataSourceComponent ...
// NOTE: Generator extends the Component interface and DataSourceComponent does not
generator.release();
The enforcement would be that all Components are assumed to be ThreadSafe in implementation,
with the exception of those whose interfaces will not allow it. In those cases, the
Components will be pooled, and extend the Component interface that will look like this:
interface Component
{
void release();
}
This approach simplifies the use of the Component infrastructure tremendously as we no
longer have to have big complex try/catch/finally methods to ensure that we release
all components even if they are ThreadSafe.
Also by enforcing the lifestyle of the Components like this, we encourage threadsafety
as a system goal--which does increase the efficiency of using system resources.
Of course, we could address the whole issue by returning to the concept that all Components
must be ThreadSafe, and in the cases of a Transformer that extends ContentHandler it would
have to be changed like this:
interface Transformer
{
XMLFilter getFilter(Context context, String source, Parameters);
}
That way, the part of the interface that precluded the Transformer from being ThreadSafe
returns a unique instance to be used in the Pipeline.
In the end, this may be the best option in all, and we would have to beef up the Developing
With Avalon paper even more to teach these principles.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi again Leo,
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, January 10, 2002 5:00 PM
>
> > -----Original Message-----
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > Sent: den 10 januari 2002 16:37
> >
> > Hi Berin and Leo,
> >
> >
> > IMO any of those solutions cuts reusability and mix concerns.
>
> I don't see how this is. If the CM interface can not be used to
> lookup anything but components, then that is fine. If you need to
> look up something else, define a new interface - XManager - and
> use it to lookup Xs.
>
> Now if you are talking about the ECM implementation, then that's
> something else entirely.
I think that there should be a very generic ComponentManager
interface, a very generic ECM, and then some room for domain
specific ComponentManagers, possibly with their own lookup()
methods as convenient as possible for the keys used in such domain.
Of course that maybe one or two "ECM" implementations still make
sense and they can wrap the "GenericECM" to offer the old way
lookup format:
lookup(String role)
lookup(String role, String hint)
and the Context format:
lookup(String role)
lookup(String role, Context hint)
Again, there are few things more generic that the "component"
concept. IMO a "X" is a component too!
=:o)
> > - Now look at the current situation where most tools are so happy
> > just working with a String role and a String hint. The context
> > object is much heavier to build, but on CPU and keystrokes!
> > This makes those that just want the simple version to pay an
> > extra cost because of the "complicated guys".
>
> The time taken to lookup the component would have to be significant
> compared to the time it takes to use it before it becomes a problem.
I do not hesitate on adding this kind of light overhead WHEN to get
an advantage for which I see no easy-enough cheaper way (like with
the "token" method to track resources from my previous post).
However, in this case I see a cheaper and easy-enough way.
> > ...
> >
> > Sorry, but I do not understand why is the ComponentSelector
> > necessary. You can always achieve the same with a composite key.
>
> Yes, but...
>
> > You can still use a ComponentSelector as an "implementation"
> > detail if the indexing strategy is flexible enough.
> >
> > Obviously, the indexing strategy has to do with the algorithm
> > used to build the key of the object and that will be domain
> > specific. And the components for a given domain that need to
> > access other components from the ComponentManager must know
> > what indexing strategy is being used.
>
> ...and this is where your strategy fails. As long as we allow
> Composable components, the component itself will be tied to
> the domain (and indexing method) - as it must know how to look
> up other components.
It ALREADY must know. It must know that there is a "role" and
sometimes a "hint".
My domain is completely different. I do not want to use ANY of
the components from James or something like that but I still
could use the ComponentManager and most of the related stuff.
Besides, even changing naming strategy I could still use a lot
of Avalon components, like Database connection pools and other
components that do not call the ComponentManager just by
changing the strategy used to build their key.
And besides this "top" ones, I could probably adapt many others
just by extending them - as by extending and changing the
database connection pool method used to get a Janitor from the
ComponentManager (if or when the db pool gets one).
> > Application domains can be completely different. I don't give
> > a sh*t for Sockets and SocketPools as James will and James
> > possibly does not need to name components as I do. Ant has
> > probably some other indexing needs.
>
> But can these needs not be solved without reworking the CM?
>
> /LS
Yes, I FORKED!
=:o)
That is how I learned so much about Avalon.
Argh! It would be much less effort to stay ignorant!
=;o)
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: den 10 januari 2002 16:37
> To: Avalon Developers List
> Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> Hi Berin and Leo,
>
>
> IMO any of those solutions cuts reusability and mix concerns.
I don't see how this is. If the CM interface can not be used to
lookup anything but components, then that is fine. If you need to
look up something else, define a new interface - XManager - and
use it to lookup Xs.
Now if you are talking about the ECM implementation, then that's
something else entirely.
> - Now look at the current situation where most tools are so happy
> just working with a String role and a String hint. The context
> object is much heavier to build, but on CPU and keystrokes!
> This makes those that just want the simple version to pay an
> extra cost because of the "complicated guys".
The time taken to lookup the component would have to be significant
compared to the time it takes to use it before it becomes a problem.
> On the other hand, we can have a ComponentManager that implements
> the above mentioned functionality accepting a separate indexing
> strategy and then wrap it according to our usage. One possible
> wrapper would just have the old style interface with:
> Object lookup( String role )
> {
> super.lookup(role);
> }
>
> Object lookup( String role, String hint );
> {
> super.lookup(new RoleAndHint(role, hint));
> }
>
> For the scripting guy just:
> Object lookup( String name )
> {
> super.lookup(name);
> }
>
> For the localized, "sessioned", complicated guy:
> =;o)
> Object lookup(String name, Context, ctx)
> {
> super.lookup(new NameAndCtx(name, ctx));
> }
>
> Sorry, but I do not understand why is the ComponentSelector
> necessary. You can always achieve the same with a composite key.
Yes, but...
> You can still use a ComponentSelector as an "implementation"
> detail if the indexing strategy is flexible enough.
>
> Obviously, the indexing strategy has to do with the algorithm
> used to build the key of the object and that will be domain
> specific. And the components for a given domain that need to
> access other components from the ComponentManager must know
> what indexing strategy is being used.
...and this is where your strategy fails. As long as we allow
Composable components, the component itself will be tied to
the domain (and indexing method) - as it must know how to look
up other components.
> Application domains can be completely different. I don't give
> a sh*t for Sockets and SocketPools as James will and James
> possibly does not need to name components as I do. Ant has
> probably some other indexing needs.
But can these needs not be solved without reworking the CM?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin and Leo,
IMO any of those solutions cuts reusability and mix concerns.
Lets take a look at ExcaliburComponentManager - it does a LOT of
very useful and smart stuff besides the specific strategy it uses
to "index" stuff - all that checking that makes it safer and all
that logging that makes much easier to hunt any existing bugs...
...and there could be more.
Maybe that indexing (Mapping) strategy should just be separated.
What is the use?
- Imagine that I want to use a Component Manager to supply global
resources for a scripting/templating tool. It might happen that
I only want to index components by name, whatever their role is.
- Now look at the current situation where most tools are so happy
just working with a String role and a String hint. The context
object is much heavier to build, but on CPU and keystrokes!
This makes those that just want the simple version to pay an
extra cost because of the "complicated guys".
On the other hand, we can have a ComponentManager that implements
the above mentioned functionality accepting a separate indexing
strategy and then wrap it according to our usage. One possible
wrapper would just have the old style interface with:
Object lookup( String role )
{
super.lookup(role);
}
Object lookup( String role, String hint );
{
super.lookup(new RoleAndHint(role, hint));
}
For the scripting guy just:
Object lookup( String name )
{
super.lookup(name);
}
For the localized, "sessioned", complicated guy:
=;o)
Object lookup(String name, Context, ctx)
{
super.lookup(new NameAndCtx(name, ctx));
}
Sorry, but I do not understand why is the ComponentSelector
necessary. You can always achieve the same with a composite key.
You can still use a ComponentSelector as an "implementation"
detail if the indexing strategy is flexible enough.
Obviously, the indexing strategy has to do with the algorithm
used to build the key of the object and that will be domain
specific. And the components for a given domain that need to
access other components from the ComponentManager must know
what indexing strategy is being used.
Application domains can be completely different. I don't give
a sh*t for Sockets and SocketPools as James will and James
possibly does not need to name components as I do. Ant has
probably some other indexing needs.
But all these domains can enjoy a common set of checkings and
logging functionality.
I still see a couple of issues on the configuration step. Mine
works differently and solves some of those issues, but I think
it does not solve them all. However, those obstacles do not
look impossible to beat.
What do you think?
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, January 10, 2002 3:28 PM
> To: Avalon Developers List
> Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > interface ComponentManager
> > {
> > Object lookup( String role );
> > Object lookup( String role, Context hint );
> > }
>
> Berin,
>
> the snippet above, I think, would be ideal. I also think that
> the lookup(String, Context) method should work like this:
>
> public Object lookup( String role, Context hint )
> {
> Object component = lookup (role);
>
> if ( component instanceof ComponentSelector)
> {
> return component.lookup (hint);
> }
> else
> {
> return component;
> }
> }
>
> Since the Context may have, for example, HttpRequests, I
> do not want to let the CM interpret the contents of it.
>
> BTW, do we dump the Component interface?
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> interface ComponentManager
> {
> Object lookup( String role );
> Object lookup( String role, Context hint );
> }
Berin,
the snippet above, I think, would be ideal. I also think that
the lookup(String, Context) method should work like this:
public Object lookup( String role, Context hint )
{
Object component = lookup (role);
if ( component instanceof ComponentSelector)
{
return component.lookup (hint);
}
else
{
return component;
}
}
Since the Context may have, for example, HttpRequests, I
do not want to let the CM interpret the contents of it.
BTW, do we dump the Component interface?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>Hi Leo,
>>
>>I agree with you BUT I am not talking about that.
>>
>>I am not talking about changing the type of a Role but about changing
>>the type (and name) of the parameter for ComponentManager.lookup()
>>from:
>> ComponentManager.lookup(String role)
>>to:
>> ComponentManager.lookup(Object query)
>>
>
> Yes, but the query object sent in must match something in the configuration
> of the component manager. That is, for every query object, one must be able
> to specify something in the configuration to guarantee that the query object
> results in just that component.
>
> I just see this as making the CM much harder to use - how does the Composable
> component know what query to pass to the CM? How does the CM know how to
> parse an NDimQuery?
>
> The way I see it, the power of the CM lies in not letting the Composable
> specify *too much* what it wants. The more intricate queries you allow the
> Composable to send, the more complex is the contract between the Composable
> and the CM and the higher the coupling.
Paulo and Leo,
I spent some time thinking about it last night, and I think the perfect Query
Object would be our very own Context.
It would operate something like this:
ComponentQuery query = new ComponentQuery ();
manager.lookup( query.role( MyComponent.ROLE, myContext ) );
The ComponentQuerywould be an interface similar to this:
interface ComponentQuery
{
RoleContext role( String role );
RoleContext role( String role, Context hints );
}
The RoleContext is an object that implements the Context interface, and can
allow any number of hints necessary for the system. The interface for the
RoleContext would be something like this:
interface RoleContext extends Context
{
String getRole();
}
The ComponentManager would only use the Role if that is all that is needed.
If there are multiple Components to choose from for the same Role, the
ComponentManager is in charge of the logic to use the hints supplied in the
Context. The Objects stored in the Context are merely used as hints--nothing
more.
This allows the ComponentManager to be in charge of the query itself.
Of course all this could be simplified with the following changes to the
ComponentManager interface:
interface ComponentManager
{
Object lookup( String role );
Object lookup( String role, Context hint );
}
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
>
> > If we had non-string roles, configuration would be much harder,
> > I'm afraid.
>
> Hi Leo,
>
> I agree with you BUT I am not talking about that.
>
> I am not talking about changing the type of a Role but about changing
> the type (and name) of the parameter for ComponentManager.lookup()
> from:
> ComponentManager.lookup(String role)
> to:
> ComponentManager.lookup(Object query)
Yes, but the query object sent in must match something in the configuration
of the component manager. That is, for every query object, one must be able
to specify something in the configuration to guarantee that the query object
results in just that component.
I just see this as making the CM much harder to use - how does the Composable
component know what query to pass to the CM? How does the CM know how to
parse an NDimQuery?
The way I see it, the power of the CM lies in not letting the Composable
specify *too much* what it wants. The more intricate queries you allow the
Composable to send, the more complex is the contract between the Composable
and the CM and the higher the coupling.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
> If we had non-string roles, configuration would be much harder,
> I'm afraid.
Hi Leo,
I agree with you BUT I am not talking about that.
I am not talking about changing the type of a Role but about changing
the type (and name) of the parameter for ComponentManager.lookup()
from:
ComponentManager.lookup(String role)
to:
ComponentManager.lookup(Object query)
This is according to the previous discussion on this thread and just
means that what you use as a key is up to the implementation.
Examples:
- I want to use named components, and get them by name whatever is
their role:
myComp = cm.lookup("mycomponent");
- I want to use named components, and get them by name and role:
myComp = cm.lookup(new RoleNameQuery("role", "mycomponent"));
- I want to use some other n-dimensional key:
myComp = cm.lookup(new NDimQuery("role", local, "mycomp", xpto, ...));
And role is still a name for configuration and all.
=:o)
Have fun,
Paulo
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, January 10, 2002 12:16 PM
> To: Avalon Developers List; paulo.gaspar@krankikom.de
> Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
>
>
>
>
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> >
> > Hi again, answer inline:
> >
> > > From: Peter Donald [mailto:peter@apache.org]
> > > However if you recall back to our original discussions on
> > > ComponentManager vs
> > > ComponentSelector vs NamedComponentManager. I didn't really like
> > > NamedComponentManager or ComponentSelector and tried to stop it
> > > but gave up -
> > > it was 3 vs 1 and even I get bored of arguing ... well on very
> > > rare occasions
> > > ;)
> >
> > I also see no need for the ComponentSelector as a main component
> > interface. I think it is even a bit confusing. It should just be
> > an "implementation detail".
> >
> > I also like much more the idea of having _some_ unique key that
> > we probably should avoid calling Role. Maybe it should even be
> > just an java.lang.Object key.
>
> I tried non-string roles in my C++ port of Avalon and the results
> were less than optimal. The reason is that roles are one of those
> attributes that are configured by the end user of the system -
> they appear in the XML configuration files that maps roles to
> component implementation classes.
>
> If we had non-string roles, configuration would be much harder,
> I'm afraid.
>
> For the component selector, this is not a problem - we can have
> non-string hints, as the selector "knows" what type to expect.
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
>
> Hi again, answer inline:
>
> > From: Peter Donald [mailto:peter@apache.org]
> > However if you recall back to our original discussions on
> > ComponentManager vs
> > ComponentSelector vs NamedComponentManager. I didn't really like
> > NamedComponentManager or ComponentSelector and tried to stop it
> > but gave up -
> > it was 3 vs 1 and even I get bored of arguing ... well on very
> > rare occasions
> > ;)
>
> I also see no need for the ComponentSelector as a main component
> interface. I think it is even a bit confusing. It should just be
> an "implementation detail".
>
> I also like much more the idea of having _some_ unique key that
> we probably should avoid calling Role. Maybe it should even be
> just an java.lang.Object key.
I tried non-string roles in my C++ port of Avalon and the results
were less than optimal. The reason is that roles are one of those
attributes that are configured by the end user of the system -
they appear in the XML configuration files that maps roles to
component implementation classes.
If we had non-string roles, configuration would be much harder,
I'm afraid.
For the component selector, this is not a problem - we can have
non-string hints, as the selector "knows" what type to expect.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi again, answer inline:
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Wednesday, January 09, 2002 9:56 PM
>
> ...
>
> However if you recall back to our original discussions on
> ComponentManager vs
> ComponentSelector vs NamedComponentManager. I didn't really like
> NamedComponentManager or ComponentSelector and tried to stop it
> but gave up -
> it was 3 vs 1 and even I get bored of arguing ... well on very
> rare occasions
> ;)
I also see no need for the ComponentSelector as a main component
interface. I think it is even a bit confusing. It should just be
an "implementation detail".
I also like much more the idea of having _some_ unique key that
we probably should avoid calling Role. Maybe it should even be
just an java.lang.Object key.
Hey, it is not so weird: the Context also has an Object key and
after being quite skeptical about that I ended up learning it is
the best way... not to talk about java.util.Map!!!
> Personally I used to think hierarchical ComponentManagers was the
> go ... but I think your Query object is another interesting idea.
Hierarchical is interesting but than you get a bit lost at times
just like with JNDI. It is better if one is not pushed in that
direction but can still go there, as it happens with the Query
solution.
> > The issue is that we need to figure out what to do to handle
> n-dimensional
> > lookup. Is the Query Object idea worth persuing?
>
> Persue = yes, put in framework imediately = no. I think it is a
> good idea to
> look at this and it matches somethings found in some service
> directories. For
> instance it is similar to JMX where the "name" is essentially
> made up by a
> listing of attributes - so their lookup strings look like
>
> MyDomain:role=com.biz.Foo,type=DefaultFoo,capacity=3,...
>
> And you can search for services based on their attributes.
Very directory service like. Looks like LDAP.
=:o)
> > BTW, Such a fundamental change might require a 5.0 path for Framework.
> > That would allow us to clean some other stuff up in the mean time.
>
> Definetly. Other things work looking at
>
> * remove all deprecated stuff
> * reconsider removing Component interface
YESSSssss!!!
> * reconsider not having Initializable/Disposable in separate interfaces
Great!
> * consider adding a base class that implements all the activity interfaces
I have one, with checks and all!!!
(Ok, you probably have 2 or 3!)
> * consider removing ThreadSafe and friends
Yesss!!!!
> * consider adding a Level object to logger and extra methods
>
> log( Level, message )
> log( Level, message, exception )
Argh! I used to believe on that one and then went the Avalon
way. I find the interface much cleaner.
Which experience makes you change your mind on this one?
> I already have a fork that does this.
Cool! I am curious!
> However it may be a good idea to change package names so I can continue
> relying on Framework4.0 until next version is ready. Perhaps
> something like
>
> org.apache.framework
> org.apache.avalon.framework2
>
> or similar
>
> --
> Cheers,
>
> Pete
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Thu, 10 Jan 2002 01:58, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Wed, 9 Jan 2002 03:12, Berin Loritsch wrote:
> >>I think we have come to the conclusion that Poolable interface is not
> >>helpful, and makes certain things more difficult. The remainder of the
> >>discussion has been what *else* people have found limiting. If Avalon
> >>is not to be moved into absolescence, it must learn from its limitations.
> >>Periodically we need to discuss what works and what does not work.
> >
> > Agreed - lets throw out ComponentSelector and possibly Component
> > interface
> >
> > /me runs and ducks for cover ;)
>
> Wow, I actually thought you were going to be the one Poo-Pooing the whole
> idea.
I would -1 a backwards incompatible change. However a new major version that
threw compatability to the wind .... that would be kool with me. The main
reason is that we have not broken back compatability yet except with one
minor issue (serialized form of Configuration objects) which is one of the
reasons I was able to get some local peeps to rely on framework. I really
like the idea of it being stable - even if it has a few uglies.
However if you recall back to our original discussions on ComponentManager vs
ComponentSelector vs NamedComponentManager. I didn't really like
NamedComponentManager or ComponentSelector and tried to stop it but gave up -
it was 3 vs 1 and even I get bored of arguing ... well on very rare occasions
;)
Personally I used to think hierarchial ComponentManagers was the go ... but I
think your Query object is another interesting idea.
> The issue is that we need to figure out what to do to handle n-dimensional
> lookup. Is the Query Object idea worth persuing?
Persue = yes, put in framework imediately = no. I think it is a good idea to
look at this and it matches somethings found in some service directories. For
instance it is similar to JMX where the "name" is essentially made up by a
listing of attributes - so their lookup strings look like
MyDomain:role=com.biz.Foo,type=DefaultFoo,capacity=3,...
And you can search for services based on their attributes.
> BTW, Such a fundamental change might require a 5.0 path for Framework.
> That would allow us to clean some other stuff up in the mean time.
Definetly. Other things work looking at
* remove all deprecated stuff
* reconsider removing Component interface
* reconsider not having Initializable/Disposable in separate interfaces
* consider adding a base class that implements all the activity interfaces
* consider removing ThreadSafe and friends
* consider adding a Level object to logger and extra methods
log( Level, message )
log( Level, message, exception )
I already have a fork that does this.
However it may be a good idea to change package names so I can continue
relying on Framework4.0 until next version is ready. Perhaps something like
org.apache.framework
org.apache.avalon.framework2
or similar
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 9 Jan 2002 03:12, Berin Loritsch wrote:
>
>>I think we have come to the conclusion that Poolable interface is not
>>helpful, and makes certain things more difficult. The remainder of the
>>discussion has been what *else* people have found limiting. If Avalon
>>is not to be moved into absolescence, it must learn from its limitations.
>>Periodically we need to discuss what works and what does not work.
>>
>
> Agreed - lets throw out ComponentSelector and possibly Component interface
>
> /me runs and ducks for cover ;)
Wow, I actually thought you were going to be the one Poo-Pooing the whole
idea.
The issue is that we need to figure out what to do to handle n-dimensional
lookup. Is the Query Object idea worth persuing?
BTW, Such a fundamental change might require a 5.0 path for Framework.
That would allow us to clean some other stuff up in the mean time.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>>Agreed - lets throw out ComponentSelector and possibly Component
>>interface
>>
>>/me runs and ducks for cover ;)
>>
>
> LOL, I'm saving this email for prosperity!
:)
Prosperity or Posterity?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Stephen McConnell <mc...@osm.net>.
> Agreed - lets throw out ComponentSelector and possibly Component
> interface
>
> /me runs and ducks for cover ;)
LOL, I'm saving this email for prosperity!
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Wednesday, January 09, 2002 9:18 AM
>
> On Wed, 9 Jan 2002 03:12, Berin Loritsch wrote:
> > I think we have come to the conclusion that Poolable interface is not
> > helpful, and makes certain things more difficult. The remainder of the
> > discussion has been what *else* people have found limiting. If Avalon
> > is not to be moved into absolescence, it must learn from its
> limitations.
> > Periodically we need to discuss what works and what does not work.
>
> Agreed - lets throw out ComponentSelector and possibly Component
> interface
>
> /me runs and ducks for cover ;)
>
> --
> Cheers,
>
> Pete
LOL!
Actually I am starting to find the ComponentSelector concept more
interesting. But yeah! Kill the Component interface!
=:o)
However, I am not so sure if it is possible to build a ComponentManager
that suites all needs and if it really matters.
I mean, the ComponentManager is not the most reusable bit of Avalon and
for many projects neither is it the most interesting. I find it more
important to make as many parts as possible usable without assuming
there will be a component manager.
Note: I still love the "life cycle" stuff.
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Peter Donald <pe...@apache.org>.
On Wed, 9 Jan 2002 03:12, Berin Loritsch wrote:
> I think we have come to the conclusion that Poolable interface is not
> helpful, and makes certain things more difficult. The remainder of the
> discussion has been what *else* people have found limiting. If Avalon
> is not to be moved into absolescence, it must learn from its limitations.
> Periodically we need to discuss what works and what does not work.
Agreed - lets throw out ComponentSelector and possibly Component interface
/me runs and ducks for cover ;)
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, January 09, 2002 9:26 PM
>
>
> Paulo Gaspar wrote:
>
> > Here we go again...
> > =:o)
> >>My solution has a formal "CommandManager" that allows any Component to
> >>drop a Command into it's queue and have it executed when the processing
> >>thread is ready. This allows 1 or maybe even 2 threads handle all
> >>asynchronous management for all pools.
> >>
> >
> > My ThreadPool just accepts a Runner or Action. I thought I got it from
> > Avalon too. I am sure it was from somewhere in Jakarta (Commons?).
> >
> > Isn't that enough?
>
>
> What about growing the initial size of the pool asynchronously so that
> the system can continue initializing in the mean time. There will always
> be odd jobs to do (Is that connection still good?) in the barckground,
> and it is easier to implement if there is one common interface to do it
> all.
My confusion. Only later in my text did I correct ThreadPool to Scheduler!
I have an inner Runnable on the pool that is register with the Scheduler
and performs such cleanup operations.
> >>By adding the Concept of a PoolManager, we would have one manager for
> >>n pools. That manager houses all the logic for the managed pools.
> >>
> >
> > What does the PoolManager extra besides the threading stuff?
>
>
> It also manages the adaptive pool size depending on Time of Day and
> Day of Week, or whatever algorithm you want to use.
>
> It has the ability to derive the optimal pool size based on historical
> information--if the manager is so inclined.
Ok, you have several strategies that you might apply to a pool.
I even start seeing some usefulness on being able to register several
"PoolManagers" per Pool. Like, I want this pool with:
- Check 3 connections for old age each 5';
- Check 2 Connections for validity each 2';
- Close all connections at 4:00 AM;
- Put minimum connections at 50 just before rush hour;
- Cut down minimum connections after rush hour.
See? Piece by piece, maybe with the first 2 a bit enforced.
You got me a nice idea!
> >>>The interesting new bit at Avalon is already the ability to
> >>>serialize back to disk the new/adapted configuration of such
> >>>adaptive components.
> >>>=:o)
> >>>
> >>
> >>It's not implemented yet, but it will be.
> >>
> >
> > Doesn't the "DefaultConfigurationSerializer" work already?
>
>
> Yes (still needs work for namespaced configuration objects). There
> is no formal framework for the bidirectional management of the
> Configuration file yet.
For simple stuff it could be already very helpful.
2 way tools are dangerous. Ask Borland!!!
(Their first development tool with 2 way tools got very late. Rumors
say it was the 2 way bit. (Was it DBase IV?))
> >>>The most interesting bit of dynamic management, for me, is
> >>>interaction trough some user interface tool. Looking at metrics,
> >>>changing parameters on the run and saving the configuration
> >>>with beautiful and easy to use tools... what a nice dream!
> >>>=:oD
> >>>
> >>
> >>That is what Profile (Avalon instrumentation) will allow. I proposed
> >>to JMeter to have their metering abilities expanded, but for now
> >>they have not responded to my message. I will repost when I have
> >>an implementation of Profile in place.
> >>
> >>Another piece would be the GUI configuration.
> >>
> >
> > Isn't Peter working on some JMX based tool already?
>
>
> I think so... But that is for Phoenix. The core API does not use JMX.
If it is somewhere, it will get used and copied/ported somewhere else!
=;o)
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> Here we go again...
> =:o)
>>My solution has a formal "CommandManager" that allows any Component to
>>drop a Command into it's queue and have it executed when the processing
>>thread is ready. This allows 1 or maybe even 2 threads handle all
>>asynchronous management for all pools.
>>
>
> My ThreadPool just accepts a Runner or Action. I thought I got it from
> Avalon too. I am sure it was from somewhere in Jakarta (Commons?).
>
> Isn't that enough?
What about growing the initial size of the pool asynchronously so that
the system can continue initializing in the mean time. There will always
be odd jobs to do (Is that connection still good?) in the barckground,
and it is easier to implement if there is one common interface to do it
all.
>>By adding the Concept of a PoolManager, we would have one manager for
>>n pools. That manager houses all the logic for the managed pools.
>>
>
> What does the PoolManager extra besides the threading stuff?
It also manages the adaptive pool size depending on Time of Day and
Day of Week, or whatever algorithm you want to use.
It has the ability to derive the optimal pool size based on historical
information--if the manager is so inclined.
>>>The interesting new bit at Avalon is already the ability to
>>>serialize back to disk the new/adapted configuration of such
>>>adaptive components.
>>>=:o)
>>>
>>
>>It's not implemented yet, but it will be.
>>
>
> Doesn't the "DefaultConfigurationSerializer" work already?
Yes (still needs work for namespaced configuration objects). There
is no formal framework for the bidirectional management of the Configuration
file yet.
>>>The most interesting bit of dynamic management, for me, is
>>>interaction trough some user interface tool. Looking at metrics,
>>>changing parameters on the run and saving the configuration
>>>with beautiful and easy to use tools... what a nice dream!
>>>=:oD
>>>
>>
>>That is what Profile (Avalon instrumentation) will allow. I proposed
>>to JMeter to have their metering abilities expanded, but for now
>>they have not responded to my message. I will repost when I have
>>an implementation of Profile in place.
>>
>>Another piece would be the GUI configuration.
>>
>
> Isn't Peter working on some JMX based tool already?
I think so... But that is for Phoenix. The core API does not use JMX.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Here we go again...
=:o)
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, January 09, 2002 8:38 PM
>
>
> Paulo Gaspar wrote:
>
> ...
>
> > Ah! The kind of adaptive caching I recently discussed with Stefano
> > on the Cocoon list!!! I love that!
>
>
> Yes, but unlike Stefano's proposal, the tests are performed outside
> the critical path.
You can always have a thread taking care of cleaning up (more on the
Janitor thing will follow) and measurements must always stay in the
way.
> >>Also, for a cache implementation example, the asynchronous
> >>process will check the
> >>validity of the entries in the Cache, and automatically purge
> >>stale entries. That
> >>way the Cache does not have to perform that check synchronously.
> >>
> >
> > But any cache usually has a "janitor" (using a Cocoon term) to do
> > that.
>
>
> :) Imagine having 20 pools each with their own "janitor" to use the
> Cocoon Store idiom. Each Janitor has it's own thread--that's 20 threads.
I think I saw a Sitemap which syntax/structure suggested a separate
Janitor.
Anyway, that is what I am using: a separate Janitor (Scheduler+ThreadPool)
for several pools. My pool implementation already accepts a Scheduler to
use for running its cleanup stuff.
This way you can have something like this:
<janitor name="my-janitor" .... >
...
</janitor>
<db name="mydb1" janitor="my-janitor" url= ... >
...
</db>
<db name="mydb2" janitor="my-janitor" url= ... >
...
</db>
> My solution has a formal "CommandManager" that allows any Component to
> drop a Command into it's queue and have it executed when the processing
> thread is ready. This allows 1 or maybe even 2 threads handle all
> asynchronous management for all pools.
My ThreadPool just accepts a Runner or Action. I thought I got it from
Avalon too. I am sure it was from somewhere in Jakarta (Commons?).
Isn't that enough?
> By adding the Concept of a PoolManager, we would have one manager for
> n pools. That manager houses all the logic for the managed pools.
What does the PoolManager extra besides the threading stuff?
> > ...
> >
> > The interesting new bit at Avalon is already the ability to
> > serialize back to disk the new/adapted configuration of such
> > adaptive components.
> > =:o)
>
>
> It's not implemented yet, but it will be.
Doesn't the "DefaultConfigurationSerializer" work already?
> > The most interesting bit of dynamic management, for me, is
> > interaction trough some user interface tool. Looking at metrics,
> > changing parameters on the run and saving the configuration
> > with beautiful and easy to use tools... what a nice dream!
> > =:oD
>
>
> That is what Profile (Avalon instrumentation) will allow. I proposed
> to JMeter to have their metering abilities expanded, but for now
> they have not responded to my message. I will repost when I have
> an implementation of Profile in place.
>
> Another piece would be the GUI configuration.
Isn't Peter working on some JMX based tool already?
> <snip>All the other tasty stuff that I need to take alot
>
> of time to review</snip>
=:o)
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> Hi Berin,
>
>>Because the management is no longer performed synchronously.
>>Instead of managing
>>pool sizes as objects are requested and returned to the pool,
>>they are managed by
>>an asynchronous process. That asynchronous process will have the
>>intelligence to
>>predict the optimal pool size so that all get() requests pass
>>without wasting resources.
>>
>
> Ah! The kind of adaptive caching I recently discussed with Stefano
> on the Cocoon list!!! I love that!
Yes, but unlike Stefano's proposal, the tests are performed outside
the critical path.
>>Also, for a cache implementation example, the asynchronous
>>process will check the
>>validity of the entries in the Cache, and automatically purge
>>stale entries. That
>>way the Cache does not have to perform that check synchronously.
>>
>
> But any cache usually has a "janitor" (using a Cocoon term) to do
> that.
:) Imagine having 20 pools each with their own "janitor" to use the
Cocoon Store idiom. Each Janitor has it's own thread--that's 20 threads.
My solution has a formal "CommandManager" that allows any Component to
drop a Command into it's queue and have it executed when the processing
thread is ready. This allows 1 or maybe even 2 threads handle all
asynchronous management for all pools.
By adding the Concept of a PoolManager, we would have one manager for
n pools. That manager houses all the logic for the managed pools.
>>When management of resources are moved outside of the critical
>>path of execution,
>>the critical path is shorter and simpler.
>>Shorter and simpler == faster.
>>
>
> Ok, of course.
>
> This kind of things I have already been wondering about and you
> can do most without changing the ComponentManager.
>
> I thought you had some new black magic!
> =;o)
>
> The interesting new bit at Avalon is already the ability to
> serialize back to disk the new/adapted configuration of such
> adaptive components.
> =:o)
It's not implemented yet, but it will be.
> The most interesting bit of dynamic management, for me, is
> interaction trough some user interface tool. Looking at metrics,
> changing parameters on the run and saving the configuration
> with beautiful and easy to use tools... what a nice dream!
> =:oD
That is what Profile (Avalon instrumentation) will allow. I proposed
to JMeter to have their metering abilities expanded, but for now
they have not responded to my message. I will repost when I have
an implementation of Profile in place.
Another piece would be the GUI configuration.
<snip>All the other tasty stuff that I need to take alot
of time to review</snip>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin,
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, January 09, 2002 5:10 PM
>
> Paulo Gaspar wrote:
>
>
> > ...
> >
> > The SingleThreaded components I have that are not pooled are very light
> > anyway. In the whole picture of the many objects created and destroyed
> > to process a request they are not a representative extra load for the
> > garbage collector.
>
>
> Modern JVM's are very efficient when all you are doing is creating a new
> instance of a small final class (as close as Java will ever get to a C
> 'struct'). The problem occurs when the cost of creating a new Component
> also involves running it through a lifecycle, or it is an expensive
> resource like a Database Connection object.
That was my understanding too.
> > If it is a "ComponentHandler", I keep having those. My names
> are different
> > but you could call them:
> > - ThreadSafeComponentHandler
> > - SingleThreadedComponentHandler
>
> Yup. That's what I have as well.
I copied from Avalon, remember?
=;o)
I just changed on thing in that part of the structure: I have both
an AbstractComponentHandler and a ComponentHandlerFactory.
When I was trying to understand Avalon I found confusing having together
in the AbstractComponentHandlre both:
1) The code that creates the right ComponentHandler for a Component
depending on its LifeStyle;
2) The common code (mostly life cycle management) for all
ComponentHandler implementations.
I think that 1) belongs elsewhere. I really think you should change that
bit as I did, so that:
- AbstractComponentHandler has common lifecycle code (initialization,
disposal, etc.) to all ComponentHandlers;
- ComponentHandlerFactory implements the strategy to create the right
ComponentHandler implementation.
This also makes this code more reusable in case some one comes up with
some new (and probably weird) component life style.
> > Poolable objects have their pool wrapped by a factory and are handled by
> > the SingleThreadedComponentHandler.
>
> A pool wrapped by a factory? How does that work? I am used to seeing
> a Pool use a Factory to generate instances. If you are referring to the
> Factory pattern (Design Patterns, GoF), then I can see the Pool being
> part of the "factory".
>
> I think this may be the cause of my confusion.
It is as you say.
Since I force having a ComponentFactory for each role/type registered in
the ComponentManager, for poolable objects I end up having:
- A ComponentFactory (facade?) that creates, configures and privately
holds some pool implementation, and uses that pool to act as a factory
of "SingleThreaded" (pooled) components;
- That (ComponentFactory) private Pool implementation, which usually
must be parameterized with a...
- ...pool object factory.
> > ...
> >
> > That is too complex for me to consider at the moment but I am
> very curious
> > about those new dynamic developments, like the with run-time management/
> > reconfiguration and saving the current configuration back to disk.
> >
> > Probably I will end up finding some use for those ideas too.
> > =:o)
>
>
> I am still formulating the plans in my head.
Having already considered that kind of functionality, I sure have a
(maybe still vague) idea of how tricky that is.
> >>Perhaps this goes beyond what you are thinking of. However,
> such a managed
> >>system is able to make expensive decisions about the most
> efficient way to
> >>allocate resources asynchronously from the rest of the system. That way
> >>latencies involved in lookup and releasing of components are
> minimized to
> >>simple get() and put() calls on a Map.
> >>
> >
> > This paragraph is not clear to me.
> > Why will that improve latencies so much?
>
>
> Because the management is no longer performed synchronously.
> Instead of managing
> pool sizes as objects are requested and returned to the pool,
> they are managed by
> an asynchronous process. That asynchronous process will have the
> intelligence to
> predict the optimal pool size so that all get() requests pass
> without wasting resources.
Ah! The kind of adaptive caching I recently discussed with Stefano
on the Cocoon list!!! I love that!
> Also, for a cache implementation example, the asynchronous
> process will check the
> validity of the entries in the Cache, and automatically purge
> stale entries. That
> way the Cache does not have to perform that check synchronously.
But any cache usually has a "janitor" (using a Cocoon term) to do
that.
> When management of resources are moved outside of the critical
> path of execution,
> the critical path is shorter and simpler.
> Shorter and simpler == faster.
Ok, of course.
This kind of things I have already been wondering about and you
can do most without changing the ComponentManager.
I thought you had some new black magic!
=;o)
The interesting new bit at Avalon is already the ability to
serialize back to disk the new/adapted configuration of such
adaptive components.
=:o)
The most interesting bit of dynamic management, for me, is
interaction trough some user interface tool. Looking at metrics,
changing parameters on the run and saving the configuration
with beautiful and easy to use tools... what a nice dream!
=:oD
> >>> My "ComponentHandler" still takes care of lifecycle management
> >>> operations and strategies, like:
> >>> - Initializing, starting, stopping, disposing, etc.
> >>> - Using only one instance for thread safe components and
> >>> always a new instance for the others.
> >>>
> >>
> >>That is the implementer's perogative on how they want to manage
> >>their system
> >>or define Components. However, if your system does not work with
> >>any Avalon
> >>Component, then you have lost the ability to use a number of well tested
> >>Components. Hopefully you have not lost that ability.
> >>
> >
> > Most of my components are not from the Avalon universe, hence many
> > of my choices.
>
> I see.
And I think that Avalon should be a bit more open ( = make it easier)
to those external components. But I already told you this.
> > Even with components that exist at Avalon, sometimes I needed
> > something different. I ended up building my own pool an my own
> > connection pool in order to have better control over its behavior
> > and to better control its resources.
>
> Hmmm. What additional control do you need?
I looked at several implementations and I am not 100% sure of what I
specifically missed on Avalon. The features I was missing on most
implementations I investigated were:
- Controlling the pace the pool expands and then shrinks back;
- Resource management.
By resource management, I mean closing all open ResultSets/Statements
for a Connection being returned to the pool, and I am sure that Avalon
pool implementation was missing this one.
At least the Statements must be closed. The JDBC standard demands that
when a Statement is closed its ResultSets are closed too. In my pool I
just wrap the ResultSet too to be extra sure I do not get into trouble
if a get a driver that does not conform to that. (I want to make it
optional and parameterized this ResultSet wrapping bit.)
I still miss having a client-side DataSource, but that is a feature
that many people will not miss. It works like this:
- The component you get from the ComponentManager can be a DataSource
and not a Connection;
- You can get all the Connections from the pool trough this client
DataSource;
- This client DataSource has a (non standard) close() method that
can be used to return all the Connections obtained trough it to
the pool and to terminate its use.
> >>It seems like alot of work for a Component writer to create a
> new factory
> >>for each Component. I beleive that slows development time
> unnecessarily.
> >>By having one generic ComponentFactory, you can focus on more important
> >>issues like Component interaction, and how it should handle when
> >>Components are not available.
> >>
> >
> > Actually not. The component writer just ends up moving the
> configuration
> > code from the component to its factory, and thanks to the
> auto-configuration
> > functionality, that code is much simpler.
> >
> > Since that code works based on introspection (like in Ant, as I already
> > mentioned) I even use a separate bean (or just an object with fields) to
> > be introspected and receive the configuration information.
> >
> > I end up with 3 classes:
> > - The component;
> > - The factory;
> > - The configuration bean which is usually an inner class of
> the factory.
> >
> > But overall the code is much simpler/shorter than typical Avalon code.
> >
> > And I can use 3rd party / isolated components without modifying them.
>
>
> Can you post a code example. That might help me understand where you are
> coming from.
It is at the end of this mail.
> ...
> >
> > I think that just implementing the Component interface makes no much
> > difference. It is just a marker.
>
> Probably, and Peter surprised me when he mentioned he was in favor of
> removing Component.
He sure surprised me too!
=:o)
I think the Component interface is one of those ideas that look great
and useful before you start using them. Sometimes you have to experiment
a lot before you find out what really works.
I know I am repeating something that everybody here is aware of. This
comes up in many threads I have followed.
=:o)
> > Maybe we are talking about different things?
> >
> > However, I have a role interface which ends up being validated, of
> > course. Maybe that is what you mean.
>
> When I talk about a Component's interface, this is precisely what I
> am referring to.
AH! Cool! Then we agree.
But, again, that was something I learned from Avalon.
> > My roles configuration xml format is quite different but it includes
> > both the factory class and the role class, this last one being the
> > interface of the object built by the factory.
>
> That is only a configuration issue.
Yes.
This is another point where it shoes that I am still learning your rank
of values - the things you consider core and those you consider
accessory. It all makes sense for me until now.
> > ...
> >
> > However, I still see the Selectors as a way of having more than one
> > implementation for the same role, but I have a different problem: I
> > have different implementations and different instances.
>
>
> The ComponentSelector (in Excalibur) works exactly like the
> ComponentManager.
> In effect, you have different instances of the same implementations (even
> with different configurations per instance). It works like what you need.
> You just don't like the API :).
I got lost several times with Excalibur. I think I got confused several
times also because of the configuration samples I found.
One thing that is becoming obvious to me is that ALSO with the Component
Manager you should move configuration reading to a separate class. The Gof4
Strategy pattern, me thinks.
Then the ComponentManager/RolesManager implementations should expose an API
to add new Components/Roles to that configuration strategy pattern.
But I am still thinking about this one...
If both Avalon/Excalibur and my understanding of it will evolve to the point
I can use it, I will. I want to reduce the code I take care of (75 Kloc!). I
would just place its ComponentManager inside mine, to keep the convenient
facade I have.
> > VERY interesting idea.
> >
> > The query object can even use a task/request Context for the locale/user
> > data.
>
> Precisely :)
>
> This is what makes the concept so powerful.
I like very much that Query parameter idea.
=:o)
> > ...
> >
> > The other big difference is the "token" based resource management. The
> > one that allows me to ensure that all components requested for a task
> > are released at its end:
> >
> > // start processing request
> > obj1 = cm.get(token, role1, name1);
> > obj1 = cm.get(token, role2, name2);
> > obj1 = cm.get(token, role3, name3);
> > ....
> >
> > // finish processing request
> > cm.release(token);
>
>
> What are your perceived advantages to using the Token? I say perceived,
> because in order for them to be considered real they have to be proven.
> Many times, perceived advantage is just as important as real advantage.
>
> However, we may find that token is a step in the right direction, or
> maybe not. I just want to know why you happen to like it.
This token idea probably makes no sense for many other applications, but
in my case it is the most practical way of ensuring that no resources are
lost.
Most of the objects I expose to the scripted bits and to the templates
perform some housekeeping tasks. The idea is that you never have to close
anything and never have to do any cleanup in a script.
Typical situation:
- You get a SqlQuery object, you put some parameters and you place it in
a Velocity template context;
- When the template is processed, Velocity finds out that can get an
Iterator from this SqlQuery object in some "#foreach" directive and
that (getting the Iterator) automatically opens the necessary
Connection, Statement and ResultSet;
- When processing the "#foreach" goes over the last record in the
ResultSet, all the database objects are closed (ResultSet, Statement)
or returned to the pool (Connection).
But if there is some exception, maybe something stays open.
I do not want to force the scripter to know much. I do not even want
him to care about exceptions for most cases. The system will log them,
clean up and display an as-nice-as-possible error message.
The scripter does not even know that there is a token. That much is
hidden from him/her.
And it is possible to do so because the typical resource opens very
few resources, and this way I can postpone taking care of the cleanup
to the end of the request/task process.
Of course that the programmer that uses this ComponentManager has
other options. For complex parts Java will be used instead of script
and the traditional "try" blocks can and should be used.
For me the most convenient spot to track these resources is the
ComponentManager.
For each "SingleThreaded" component (which, as you know, includes the
poolable objects) requested, the ComponentManager creates an entry for
in a ComponentTracker, which is a "per-token" list of component
entries (there is obviously a Map of lists, but there is also a Map
of tokens per Component).
It is not necessary to return "ThreadSafe" components and I just
ignore those in order to make component tracking lighter. Since most
components I use are "ThreadSafe", this thing is still fast.
It the object is returned to the ComponentManager before the
"cm.release(token);" step at the end of the request/task processing,
its entry immediately removed from the ComponentTracker.
When the you get to that "cm.release(token);" call at the end of the
request/task processing, all components still not returned are
(returned) and the token entry (the List in the Map) is removed.
Of course that I can have a SafeComponentManager with a
ComponentTracker and an inner ComponentManager. This serves both use
models.
> >>>Notice that I followed a different approach than Cocoon, where the
> >>>sitemap has almost nothing to do with the ComponentManager.
> >>>
> >>>In my implementation, the sitemap is stored in the ComponentManager.
> >>>Overall, my implementation is much, much, much simpler.
> >>>
> >>Cocoon's Sitemap is stored in a ComponentManager as well. It just needs
> >>access to a large number of other Components.
> >>
> >
> > Ops! Where?
> > Is it the new tree walking stuff?
>
> No.
Where then? Do you happen to know?
=:o)
> > It was compiled, right? (I only looked at Cocoon2.)
>
> Yes. The Sitemap is a Component that happens to be Compiled and loaded
> dynamically by the ClassLoader. While it is being used, it behaves
> exactly like any other component.
But is/has the Sitemap a ComponentManager to store its structure?
AND NOW... the sample:
// Here goes a simple DB component factory.
// This one is missing a load of parameterization but makes a better
// example. I added some comments just for this mail!
// =:o)
import java.sql.Connection;
import javax.sql.DataSource;
import krankikom.sql.pool.IDbConnFactory;
import krankikom.sql.pool.dbcfactories.DriverManagerConnectionFactory;
import krankikom.sql.pool.PoolingDataSource;
import krankikom.sql.pool.DbConnectionPool;
import krankikom.activity.AbstractLoggableActivity;
import krankikom.log.ILogger;
import krankikom.framework.component.IComponentFactory;
import krankikom.framework.configuration.configurator.*;
public class DbFactory
extends AbstractLoggableActivity
implements IAutoConfigurable, IComponentFactory
// IAutoConfigurable exposes the autoConfigXXX() methods
// that the Configurator will use to "auto-configure" this
// factory.
{
// The IFieldBasedConfig marker tells the Configurator
// to use field introspection instead of the standard
// JavaBean introspection.
// (I am too lazy to find writting setXXX() methods
// interesting for this case.)
public class CfgBean implements IFieldBasedConfig
{
public String name;
public String driver;
public String url;
public String user;
public String password;
// Silly debug helper
public String toString()
{ return getClass().getName()
+ "{ " + fmtCell("*name", name)
+ fmtCell("*driver", driver)
+ fmtCell("*url", url)
+ fmtCell("*user", user)
+ fmtCell("*pwd", "*****")
+ " }";
}
}
public CfgBean cfg = new CfgBean();
private DbConnectionPool m_dbConnPool;
public DbFactory()
{ super();
}
//*** IComponentFactory stuff: ***
public Class createdClass()
{ return java.sql.Connection.class;
}
public boolean isComponentThreadSafe()
{ return false;
}
public Object newInstance()
throws Exception
{ return m_dbConnPool.newDataSource();
}
public void release(Object i_object)
throws Exception
{
if (null != i_object)
((PoolingDataSource)i_object).close();
}
//*** IAutoConfigurable stuff: ***
public Object autoConfigBean()
{ return cfg;
}
public void autoConfigInitialize()
{}
public void autoConfigPropertiesFinalize()
{
// I still want to see a sign that it is working!!! =;o)
System.out.println("CfgBean => " + cfg);
}
public void autoConfigFinalize()
{
}
//*** Life cycle ***
// This customXXX() are called by the lifecycle methods
// at AbstractLoggableActivity which implements the
// Initializable, Disposable, Startable and Logabble
// interfaces with a bunch of checks to make sure I am
// doing things right and also logs on "INFO" level when
// he performs the life cycle methods. UFFFfffff!
public void customInitialize()
throws Exception
{ IDbConnFactory dbConnFactory =
new DriverManagerConnectionFactory(cfg.driver, cfg.url, cfg.user, cfg.password);
m_dbConnPool = new DbConnectionPool(logger(), dbConnFactory);
m_dbConnPool.setUseBorrowValidation(false);
m_dbConnPool.setUseIdleValidation(false);
m_dbConnPool.setUseReturnValidation(false);
m_dbConnPool.initialize();
}
public void customStart()
throws Exception
{ m_dbConnPool.start();
}
public void customStop()
throws Exception
{ m_dbConnPool.stop();
}
public void customDispose()
throws Exception
{ m_dbConnPool.dispose();
}
// Silly debug helpers
protected static String fmtCell(final String i_name, final String i_value)
{ return "[" + i_name + "=" + String.valueOf(i_value) + "]";
}
public String toString()
{ return cfg.toString();
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
>>ExcaliburComponentManager/Selector have the three lifestyles: ThreadSafe,
>>SingleThreaded, Poolable. The Poolable interface we all agree is
>>not beneficial
>>to the system as a whole. Also, having Components that are used only once
>>is not a good pattern as it adds undue stress on the garbage collecter and
>>only adds to the latency of looking up a Component. Therefore the point
>>of the original thread was to merge SingleThreaded and Poolable so that
>>all SingleThreaded Components are pooled.
>>
>
> That may make sense for Avalon but I am not sure it makes sense for my
> project. It would be like pooling most objects you create in a Servlet.
>
> The SingleThreaded components I have that are not pooled are very light
> anyway. In the whole picture of the many objects created and destroyed
> to process a request they are not a representative extra load for the
> garbage collector.
Modern JVM's are very efficient when all you are doing is creating a new
instance of a small final class (as close as Java will ever get to a C
'struct'). The problem occurs when the cost of creating a new Component
also involves running it through a lifecycle, or it is an expensive
resource like a Database Connection object.
>>> There is no "DefaultComponentFactory". Each type of component has its
>>> specific factory. This factory takes care of configuration too.
>>>
>>
>>In essence, you have merged the ComponentHolder and ComponentFactory into
>>one class. The ComponentFactory gives the Configuration
>>information to the Component. This works well in most situations.
>>
>
> ComponentHolder? What ComponentHolder? I do not know that one!
Sorry, that was the old name for ComponentHandler. They are equivalent.
> If it is a "ComponentHandler", I keep having those. My names are different
> but you could call them:
> - ThreadSafeComponentHandler
> - SingleThreadedComponentHandler
Yup. That's what I have as well.
> Poolable objects have their pool wrapped by a factory and are handled by
> the SingleThreadedComponentHandler.
A pool wrapped by a factory? How does that work? I am used to seeing
a Pool use a Factory to generate instances. If you are referring to the
Factory pattern (Design Patterns, GoF), then I can see the Pool being
part of the "factory".
I think this may be the cause of my confusion.
>>> (Much of this configuration cab be eased using a "configuration bean"
>>> a Configurer and a Converter, like Peter did on Ant Myrmidon proposal
>>> ...although my code already went a lot beyond what was there some 3
>>> months ago.)
>>>
>>
>>:) This is one of the things I am working on. A completely
>>managed solution.
>>By using a number of "Managers" all working independantly on
>>different parts
>>of the system. That way, the users of the Managed Container only have to
>>worry about the Components and how they are mapped together in a
>>system--all
>>reconfiguration and logger remapping are done automatically.
>>
>
> That is too complex for me to consider at the moment but I am very curious
> about those new dynamic developments, like the with run-time management/
> reconfiguration and saving the current configuration back to disk.
>
> Probably I will end up finding some use for those ideas too.
> =:o)
I am still formulating the plans in my head.
>>Perhaps this goes beyond what you are thinking of. However, such a managed
>>system is able to make expensive decisions about the most efficient way to
>>allocate resources asynchronously from the rest of the system. That way
>>latencies involved in lookup and releasing of components are minimized to
>>simple get() and put() calls on a Map.
>>
>
> This paragraph is not clear to me.
> Why will that improve latencies so much?
Because the management is no longer performed synchronously. Instead of managing
pool sizes as objects are requested and returned to the pool, they are managed by
an asynchronous process. That asynchronous process will have the intelligence to
predict the optimal pool size so that all get() requests pass without wasting
resources.
Also, for a cache implementation example, the asynchronous process will check the
validity of the entries in the Cache, and automatically purge stale entries. That
way the Cache does not have to perform that check synchronously.
When management of resources are moved outside of the critical path of execution,
the critical path is shorter and simpler. Shorter and simpler == faster.
>>> My "ComponentHandler" still takes care of lifecycle management
>>> operations and strategies, like:
>>> - Initializing, starting, stopping, disposing, etc.
>>> - Using only one instance for thread safe components and
>>> always a new instance for the others.
>>>
>>
>>That is the implementer's perogative on how they want to manage
>>their system
>>or define Components. However, if your system does not work with
>>any Avalon
>>Component, then you have lost the ability to use a number of well tested
>>Components. Hopefully you have not lost that ability.
>>
>
> Most of my components are not from the Avalon universe, hence many
> of my choices.
I see.
> Even with components that exist at Avalon, sometimes I needed
> something different. I ended up building my own pool an my own
> connection pool in order to have better control over its behavior
> and to better control its resources.
Hmmm. What additional control do you need?
>>It seems like alot of work for a Component writer to create a new factory
>>for each Component. I beleive that slows development time unnecessarily.
>>By having one generic ComponentFactory, you can focus on more important
>>issues like Component interaction, and how it should handle when
>>Components are not available.
>>
>
> Actually not. The component writer just ends up moving the configuration
> code from the component to its factory, and thanks to the auto-configuration
> functionality, that code is much simpler.
>
> Since that code works based on introspection (like in Ant, as I already
> mentioned) I even use a separate bean (or just an object with fields) to
> be introspected and receive the configuration information.
>
> I end up with 3 classes:
> - The component;
> - The factory;
> - The configuration bean which is usually an inner class of the factory.
>
> But overall the code is much simpler/shorter than typical Avalon code.
>
> And I can use 3rd party / isolated components without modifying them.
Can you post a code example. That might help me understand where you are
coming from.
>>>>And if your Role interface extends Component, you have the same
>>>>convenience--while maintaining the protection that forces you to
>>>>separate data and the interface to get the data.
>>>>
>>>>
>>>Again, the above mentioned factory makes my aware of that.
>>>
>>I won't belabor this point. I just know that a "ComponentManager"
>>that deals with Objects is open to abuse by less disciplined people
>>than yourself. For a framework, I am not convinced if it is
>>proper. Of course, I am open to understanding the motivation for
>>it.
>>
>
> I think that just implementing the Component interface makes no much
> difference. It is just a marker.
Probably, and Peter surprised me when he mentioned he was in favor of
removing Component.
> Maybe we are talking about different things?
>
> However, I have a role interface which ends up being validated, of
> course. Maybe that is what you mean.
When I talk about a Component's interface, this is precisely what I
am referring to.
> My roles configuration xml format is quite different but it includes
> both the factory class and the role class, this last one being the
> interface of the object built by the factory.
That is only a configuration issue.
>>As to Component Management, we have discussed many ideas before we came up
>>with what we have now. Among them were JNDI, strict
>>ComponentManager (i.e.
>>it was considered wrong to have multiple components for a role),
>>NamedComponentManager (with your lookup by role and name), and the current
>>ComponentManager/Selector approach.
>>
>
> I went trough that process too. JNDI included.
> =:o)
>
>
>
>>Many times, use has tempered our views of the world. Our
>>personal experience
>>deems what is more natural for us to use, and how we view our
>>world. Cocoon
>>started out down the path of the NamedComponentManager. I don't think it
>>was correct for the NamedComponent interface, but it did have a certain
>>simplicity.
>>
>>The question arose when we have n-dimensional needs for gaining
>>access to a
>>Component. For instance, a ComponentManager addresses one
>>dimension: role.
>>ComponentSelector defines a purposely loose contract so that you can use
>>any object or query objects to address all the extra dimensions that might
>>arise for future systems.
>>
>
> I think I am getting it.
>
> However, I still see the Selectors as a way of having more than one
> implementation for the same role, but I have a different problem: I
> have different implementations and different instances.
The ComponentSelector (in Excalibur) works exactly like the ComponentManager.
In effect, you have different instances of the same implementations (even
with different configurations per instance). It works like what you need.
You just don't like the API :).
>>Another interesting approach is the use of a Query object to lookup the
>>required component. The one Query object addresses as many dimensions as
>>is necessary in the system to lookup the correct component. This
>>can include
>>role, name, locale, and session information into the one lookup request.
>>
>
> VERY interesting idea.
>
> The query object can even use a task/request Context for the locale/user
> data.
Precisely :)
This is what makes the concept so powerful.
>>>It is because my problem domain is so different from Avalon's that I
>>>ended up finding that a lot could be made much simpler by changing
>>>the way the ComponentManager related stuff works.
>>>
>>And that is why I want to learn from you.
>>
>
> Well, I am already learning from you.
> =:o)
It's a mutual thing.
>>>That added complexity to the ComponentManager (still not very big) but
>>>simplified a lot the overall project.
>>>
>>>
>>>It is just one of those things that you have to play a lot with to
>>>understand why.
>>>
>>Well a short history of the decision process would help alot more than
>>playing with it.
>>
>
> In terms of interface the main difference is having the name and the
> role. Actually I have "role" (interface), "type" (implementation) and
> "name", but only "role" and "name" are lookup keys.
>
> The other big difference is the "token" based resource management. The
> one that allows me to ensure that all components requested for a task
> are released at its end:
>
> // start processing request
> obj1 = cm.get(token, role1, name1);
> obj1 = cm.get(token, role2, name2);
> obj1 = cm.get(token, role3, name3);
> ....
>
> // finish processing request
> cm.release(token);
What are your perceived advantages to using the Token? I say perceived,
because in order for them to be considered real they have to be proven.
Many times, perceived advantage is just as important as real advantage.
However, we may find that token is a step in the right direction, or
maybe not. I just want to know why you happen to like it.
>>>Notice that I followed a different approach than Cocoon, where the
>>>sitemap has almost nothing to do with the ComponentManager.
>>>
>>>In my implementation, the sitemap is stored in the ComponentManager.
>>>Overall, my implementation is much, much, much simpler.
>>>
>>Cocoon's Sitemap is stored in a ComponentManager as well. It just needs
>>access to a large number of other Components.
>>
>
> Ops! Where?
> Is it the new tree walking stuff?
No.
>
> It was compiled, right? (I only looked at Cocoon2.)
Yes. The Sitemap is a Component that happens to be Compiled and loaded
dynamically by the ClassLoader. While it is being used, it behaves
exactly like any other component.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Posted by Paulo Gaspar <pa...@krankikom.de>.
Nice discussion, lets go on:
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Tuesday, January 08, 2002 5:12 PM
>
>
> I think we have come to the conclusion that Poolable interface is not
> helpful, and makes certain things more difficult. The remainder of the
> discussion has been what *else* people have found limiting. If Avalon
> is not to be moved into absolescence, it must learn from its limitations.
> Periodically we need to discuss what works and what does not work.
>
> That is why we have the Lifestyle interfaces (real need) and Namespaces
> for Configuration objects.
>
> Paulo Gaspar wrote:
>
> > Hi Berin,
> >>Which is exactly what ExcaliburComponentManager does. There
> are necessary
> >>improvements, but they will come.
> >>
> >
> > It is quite different:
> > I have also a kind of "ComponentHandler", with a different name but
> > which implementation is also dependent on the type of the component's
> > lifecycle.
>
>
> The ComponentHandler uses a ComponentFactory that handles the
> initialization
> and destruction phases of a Component. The Container is
> responsible for the
> runtime phases (i.e. suspend()/re*()/resume() cycles). In the
> "big" picture,
> the ComponentHandler determines when to create a new instance of
> a Component
> and when to destroy an instance of a Component. The Container works with
> the ComponentHandler.
That is the general idea of my implementation too.
> ExcaliburComponentManager/Selector have the three lifestyles: ThreadSafe,
> SingleThreaded, Poolable. The Poolable interface we all agree is
> not beneficial
> to the system as a whole. Also, having Components that are used only once
> is not a good pattern as it adds undue stress on the garbage collecter and
> only adds to the latency of looking up a Component. Therefore the point
> of the original thread was to merge SingleThreaded and Poolable so that
> all SingleThreaded Components are pooled.
That may make sense for Avalon but I am not sure it makes sense for my
project. It would be like pooling most objects you create in a Servlet.
The SingleThreaded components I have that are not pooled are very light
anyway. In the whole picture of the many objects created and destroyed
to process a request they are not a representative extra load for the
garbage collector.
> > There is no "DefaultComponentFactory". Each type of component has its
> > specific factory. This factory takes care of configuration too.
>
>
> In essence, you have merged the ComponentHolder and ComponentFactory into
> one class. The ComponentFactory gives the Configuration
> information to the Component. This works well in most situations.
ComponentHolder? What ComponentHolder? I do not know that one!
If it is a "ComponentHandler", I keep having those. My names are different
but you could call them:
- ThreadSafeComponentHandler
- SingleThreadedComponentHandler
Poolable objects have their pool wrapped by a factory and are handled by
the SingleThreadedComponentHandler.
> > (Much of this configuration cab be eased using a "configuration bean"
> > a Configurer and a Converter, like Peter did on Ant Myrmidon proposal
> > ...although my code already went a lot beyond what was there some 3
> > months ago.)
>
>
> :) This is one of the things I am working on. A completely
> managed solution.
> By using a number of "Managers" all working independantly on
> different parts
> of the system. That way, the users of the Managed Container only have to
> worry about the Components and how they are mapped together in a
> system--all
> reconfiguration and logger remapping are done automatically.
That is too complex for me to consider at the moment but I am very curious
about those new dynamic developments, like the with run-time management/
reconfiguration and saving the current configuration back to disk.
Probably I will end up finding some use for those ideas too.
=:o)
> Perhaps this goes beyond what you are thinking of. However, such a managed
> system is able to make expensive decisions about the most efficient way to
> allocate resources asynchronously from the rest of the system. That way
> latencies involved in lookup and releasing of components are minimized to
> simple get() and put() calls on a Map.
This paragraph is not clear to me.
Why will that improve latencies so much?
> > My "ComponentHandler" still takes care of lifecycle management
> > operations and strategies, like:
> > - Initializing, starting, stopping, disposing, etc.
> > - Using only one instance for thread safe components and
> > always a new instance for the others.
>
>
> That is the implementer's perogative on how they want to manage
> their system
> or define Components. However, if your system does not work with
> any Avalon
> Component, then you have lost the ability to use a number of well tested
> Components. Hopefully you have not lost that ability.
Most of my components are not from the Avalon universe, hence many
of my choices.
Even with components that exist at Avalon, sometimes I needed
something different. I ended up building my own pool an my own
connection pool in order to have better control over its behavior
and to better control its resources.
> ...
>
> >>>>The next question is why make everything more "bean" like. JavaBeans,
> >>>>while usable, do have a distinct disadvantage in that they are not
> >>>>clearly marked.
> >>>>
> >>>>
> >>>I do not see much use for most pure (no methods) markers. I ended up
> >>>deleting them some 3 months ago and I do not miss them a bit.
> >>>
> >>The Idea of a Component being marked explicitly as a Component does
> >>have some value to me. It forces you to think in terms of what a
> >>Component
> >>is supposed to do. That way you don't run into the JavaBeans
> antipattern
> >>of everything (data objects included) being a Bean. You encapsulate
> >>data accessor logic apart from the data itself. It is not a correct
> >>pattern to implement Data as a Component.
> >>
> >
> > The above mentioned specific factory per component class takes care of
> > that.
>
>
> It seems like alot of work for a Component writer to create a new factory
> for each Component. I beleive that slows development time unnecessarily.
> By having one generic ComponentFactory, you can focus on more important
> issues like Component interaction, and how it should handle when
> Components are not available.
Actually not. The component writer just ends up moving the configuration
code from the component to its factory, and thanks to the auto-configuration
functionality, that code is much simpler.
Since that code works based on introspection (like in Ant, as I already
mentioned) I even use a separate bean (or just an object with fields) to
be introspected and receive the configuration information.
I end up with 3 classes:
- The component;
- The factory;
- The configuration bean which is usually an inner class of the factory.
But overall the code is much simpler/shorter than typical Avalon code.
And I can use 3rd party / isolated components without modifying them.
> > Precisely, although I often (ab)use an abstract class that puts
> > together 3 of them (Initializable, Disposable and Startable) just to
> > ease implementing some LifeCycle validation:
> > - Checking if the component is active;
> > - Making sure it is not started before being intialized;
> > - etc.
> >
> > Of course that I end up with some empty methods, but most of those
> > components have no performance issues.
>
>
> Again, your perogative to do this. I am sure you do this so that you
> limit the number of Factories you have to create. Again, I think it
> is wasteful to have to write a Factory for every type of Component,
> but it is your perogative as to how you manage your Components. Avalon
> as a framework does not enforce a specific algorithm--only a specific
> interface
Actually, most of the times I use the abstract class with those 3
interfaces its for components that are not managed by the
ComponentManager.
Again, my factories still represent much less code.
> >>>>A Role defines the logical use of the Component in the system. If
> >>>>the Role interface extends the Component interface, all the hard
> >>>>work is done for you and you don't have to recast the Component
> >>>>to release it.
> >>>>
> >>>I understand and I do not have to recast any component since my
> >>>component manager returns Object instead of Component.
>
> Of course, in either case, you have to cast it to use it.
You are right. What I meant - but wrote wrong - was that the
component does not have to implement any specific interface.
> >>And if your Role interface extends Component, you have the same
> >>convenience--while maintaining the protection that forces you to
> >>separate data and the interface to get the data.
> >>
> > Again, the above mentioned factory makes my aware of that.
>
> I won't belabor this point. I just know that a "ComponentManager"
> that deals with Objects is open to abuse by less disciplined people
> than yourself. For a framework, I am not convinced if it is
> proper. Of course, I am open to understanding the motivation for
> it.
I think that just implementing the Component interface makes no much
difference. It is just a marker.
Maybe we are talking about different things?
However, I have a role interface which ends up being validated, of
course. Maybe that is what you mean.
My roles configuration xml format is quite different but it includes
both the factory class and the role class, this last one being the
interface of the object built by the factory.
> >>>Since I focus on building components that are as independent from
> >>>the framework as possible (which makes them more reusable) I always
> >>>use a component factory. Even if only to take care of configuration.
> >>>
> >>That's fine. I just would have a hard time with a ComponentManager
> >>that is really simply an ObjectManager. That would be bad.
> >>
> >
> > I believe it is a ComponentManager... and one with several extra tasks.
> > But that has to do with the specifics of this project.
>
>
> By extending the ComponentManager interface, you can handle those extra
> tasks (hopefully).
You are right. I am talking about my standard implementation and not
about the interface.
My interface ends up being different too, because I lookup components in
a different way and because I also give a token for resource management.
This makes no sense for Avalon, but I do something like:
// start processing request
obj1 = cm.get(token, role1, name1);
obj1 = cm.get(token, role2, name2);
obj1 = cm.get(token, role3, name3);
....
// finish processing request
cm.release(token);
There is a token per task/request that can be used to tell the
ComponentManager to release all components that were not yet released for
that task/request.
This has to do with things that are very specific to my project. I do not
think that the extra overhead (although tiny) makes sense for Avalon.
> The problem with ExcaliburComponentManager is that it is not *just* a
> ComponentManager, but it is also a Container. That is merging too many
> concerns, and I want to separate the Container code from the Component
> Management code. It is best when the ComponentManager only manages access
> to Components.
If my understanding of what the container is is correct, I totally agree.
> >>>I am only focusing on the parts of what I have that can be done in
> >>>Avalon since what I have is quite a bit different.
> >>>
> >>How much so?
> >>
> >
> > Quite a lot because of the way I choused to lookup components (by role
> > AND a name), with many components for the same role, some with default
> > configuration parameters, component tracker per requester, etc.
>
>
> I have some questions on the lookup by role and name. Because Avalon
> as a framework is only concerned with the interface and enough contracts
> to specify results (not methodology), the default configuration params and
> component tracking is orthagonal to this discussion. You are perfectly
> able to do that and have your system be fully Avalon compliant.
>
> The question comes when you feel it is necessary to change the interface
> of the ComponentManager. Either Avalon is not doing something correctly,
> or it may be able to learn something.
>
> Therefore, I want to get some more information on why you felt it
> necessary to change interfaces.
>
> As to Component Management, we have discussed many ideas before we came up
> with what we have now. Among them were JNDI, strict
> ComponentManager (i.e.
> it was considered wrong to have multiple components for a role),
> NamedComponentManager (with your lookup by role and name), and the current
> ComponentManager/Selector approach.
I went trough that process too. JNDI included.
=:o)
> Many times, use has tempered our views of the world. Our
> personal experience
> deems what is more natural for us to use, and how we view our
> world. Cocoon
> started out down the path of the NamedComponentManager. I don't think it
> was correct for the NamedComponent interface, but it did have a certain
> simplicity.
>
> The question arose when we have n-dimensional needs for gaining
> access to a
> Component. For instance, a ComponentManager addresses one
> dimension: role.
> ComponentSelector defines a purposely loose contract so that you can use
> any object or query objects to address all the extra dimensions that might
> arise for future systems.
I think I am getting it.
However, I still see the Selectors as a way of having more than one
implementation for the same role, but I have a different problem: I
have different implementations and different instances.
My component manager takes care of a kind of Cocoon sitemap. Something
defined like this:
...
<db-oracle name="myDb"
url="jdbc:somedb@server:port:instance"
user="me"
password="secret" <!-- will be crypted -->
/>
<sql name="first" db="myDb" max-rows="20">
SELECT * FROM something WHERE col2 <=10
</sql>
<sql name="second" db="myDb" max-rows="20">
SELECT * FROM something WHERE col2 <=10
</sql>
...
<sitemap>
...
<panel name="body" template="simple.vm">
<run type="script" lang="pnuts">
ctx.put("list", comp.getSql("first"));
</run>
</panel>
...
</sitemap>
...
> The ComponentSelector adds a little bit of Complexity to the
> overall system,
> and an additional lookup step. In my communications with other
> CBD frameworks,
> there are other approaches we have not considered yet (or if we
> have, I don't recall).
>
> It is most common to use JNDI in J2EE frameworks. However, we
> have already
> ruled that out for Avalon as it is too heavy for resource constrained
> environments.
To heavy and harder to use. I just find JNDI too generic.
> Another interesting approach is the use of a Query object to lookup the
> required component. The one Query object addresses as many dimensions as
> is necessary in the system to lookup the correct component. This
> can include
> role, name, locale, and session information into the one lookup request.
VERY interesting idea.
The query object can even use a task/request Context for the locale/user
data.
> The manager, as it were, would make choices based on the
> information in the
> Query Object. That would allow the Components for which there was one
> entry for the role to return immediately. For Components that
> required even
> more information, the next part of the Query object was used.
>
> That does present some nice ways of expressing a system. The
> problem is creating
> a Query Object for every type of Component you have to deal with.
> In the Cocoon
> world, the Environment would be a perfect part of the Query
> Object as it addresses
> all dimensions of the problem space other than role.
Yes.
I am using a model similar to Cocoon. Very interesting ideas.
> > At first you do not see the differences. The essence looks the same.
> > It looks like I could do it the Avalon way.
>
> You probably could ;)
Maybe with an implementation a bit different from Excalibur. But I stil
like the auto-configuration/factory thing + no markers.
=:o)
> > It is because my problem domain is so different from Avalon's that I
> > ended up finding that a lot could be made much simpler by changing
> > the way the ComponentManager related stuff works.
>
> And that is why I want to learn from you.
Well, I am already learning from you.
=:o)
> > That added complexity to the ComponentManager (still not very big) but
> > simplified a lot the overall project.
> >
> >
> > It is just one of those things that you have to play a lot with to
> > understand why.
>
> Well a short history of the decision process would help alot more than
> playing with it.
In terms of interface the main difference is having the name and the
role. Actually I have "role" (interface), "type" (implementation) and
"name", but only "role" and "name" are lookup keys.
The other big difference is the "token" based resource management. The
one that allows me to ensure that all components requested for a task
are released at its end:
// start processing request
obj1 = cm.get(token, role1, name1);
obj1 = cm.get(token, role2, name2);
obj1 = cm.get(token, role3, name3);
....
// finish processing request
cm.release(token);
> > Notice that I followed a different approach than Cocoon, where the
> > sitemap has almost nothing to do with the ComponentManager.
> >
> > In my implementation, the sitemap is stored in the ComponentManager.
> > Overall, my implementation is much, much, much simpler.
>
> Cocoon's Sitemap is stored in a ComponentManager as well. It just needs
> access to a large number of other Components.
Ops! Where?
Is it the new tree walking stuff?
It was compiled, right? (I only looked at Cocoon2.)
> > I am not saying that Cocoon could be implemented this way. I am not
> > sure about that even after using quite some Cocoon code. These are
> > two different beasts, with different objectives although with many
> > things in common.
>
> You are right. Cocoon can't be implemented that way, but it can be
> cleaned up some in this regard. They are very different beasts.
As you, I am interested on finding as much common ground as possible.
Lets go on with this conversation.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>