On Fri, 2002-11-15 at 15:03, Andrew C. Oliver wrote:
> Some time ago someone sent me some ideas on how to use avalon in a
> service based strategy such that it would be more containment based
> than inheritance based (and bare will me that I regard interface
> implementation as inheritance because its "is a" not "has a").
> Basically, I don't want everything to implement 10 different interfaces.
> i'd rather null operations... So I lost the message (long story
> short, fired, lost laptop, rehired by same company in different group,
> new laptop...stupid mozilla default settings had deleted mail of my
> server against my will).. But I'm ready to do it now ;-)
I think that was me; can't find the message though.
> What I basically want is:
>
> public class AbstractService implements x, y, z, ... {
>
> ??
>
> public SomeType someLifecycleMethodImNotUsing() {
> return null;
> }
>
> }
>
> What are the x, y, and zs that I should most likely use? And what else
> do I need?
It depends on your application, granularity of components, etc. All of
the framework lifecycle interfaces could be appropriate.
Assuming that all your components are daemon-like, don't have expensive
initialization routines and don't have stuff they need to close() before
application exit:
LogEnabled
Configurable
Contextualizable
Servicable
Startable
for db-related stuff (where you need to create and destroy connections)
you will likely want
Initializable
Disposable
> In short my application is a reporting service which lets me pull from a
> number of data sources, execute various transformations and get out a
> report via various delivery methods. So I have DataProviderService
> which has for instance a JDBCService which can process QueryDefs to get
> stuff from a database (I don't ermember the names I have thus far). So
> far I've stubbed most things out and I'm fairly happy with it, but I'd
> rather not re-invent the wheel, hence my interest in using Avalon in
> place of the little "Service" and "ServiceManager" classes I used as
> placeholders..
>
> Thoughts?
- you will suffer a performance hit which may or may not matter; kinda
depends on component granularity;
- your program will be somewhat less understandable from looking at the
code (hence more prone to bugs, ....);
- us avalon peeps think you shouldn't be doing it this way;
- that said, here's a possible AbstractService (top-of-head stuff):
public abstract class AbstractService
implements LogEnabled, Contextualizable, Configurable,
Servicable, Initializable, Startable, Disposable
extends AbstractLogEnabled
{
// use these in your components to access relevant info
protected Configuration m_configuration;
protected Context m_context;
private ServiceManager m_serviceManager;
// you could check these in a runner thread you create
protected boolean m_initialized = false;
protected boolean m_started = false;
protected boolean m_stopped = false;
protected boolean m_disposed = false;
// lifecycle interfaces
public void configure( Configuration configuration )
throws ConfigurationException
{
m_configuration = configuration;
}
public void contextualize( Context context )
throws ContextException
{
m_context = context;
}
public void service( ServiceManager serviceManager )
throws ServiceException
{
m_serviceManager = serviceManager;
}
public void initialize()
throws Exception
{
m_initialized = true;
}
public void start()
throws Exception
{
m_started = true;
}
public void stop()
throws Exception
{
m_stopped = true;
}
public void dispose()
{
m_disposed = true;
}
}
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
