Re: avalon newbie: Innocent question, please don't hurt me -- services strategy with Avalon framework

[Leo Simons <le...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: avalon newbie: Innocent question, please don't hurt me -- services strategy with Avalon framework

["Andrew C. Oliver" <ac...@apache.org>]

Thanks dude!

> - you will suffer a performance hit which may or may not matter; kinda
> depends on component granularity;

Course grained.

>
> - your program will be somewhat less understandable from looking at the
> code (hence more prone to bugs, ....);

No.  looking at some things in Cocoon that does things TheRightWay(tm) 
vs the stuff in Cocoon that does it TheWrongWay..  I understand the code 
that does it the wrong way where the stuff that does it the right way I 
have to open up 20 classes to figure out what one is doing.

>
> - us avalon peeps think you shouldn't be doing it this way;

Well I can't read code that is written TheRightWay(tm) because I have to 
look up 400 bazillion different htings just to say "what the heck is 
this doing"  I write for humans not for Achedemic correctness...

Thanks again!  This is exactly what I was looking for

-Andy

> cheers,
>
> - Leo





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>