You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2002/11/15 15:03:27 UTC
avalon newbie: Innocent question, please don't hurt me -- services
strategy with Avalon framework
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 ;-)
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?
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?
thanks,
Andy
--
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
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew C. Oliver wrote:
> I've read all that.. . It left me with a "now what" feeling...
I basically said the same Leo just did, but wanted to make you write
that class... guess Leo is too sweet ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: avalon newbie: Innocent question, please don't hurt me -- services
strategy with Avalon framework
Posted by Stephen McConnell <mc...@apache.org>.
Andrew C. Oliver wrote:
> I've read all that.. . It left me with a "now what" feeling...
That's because the value-proposition hasn't been stated.
Hang on tick and I'll post something.
Steve.
>
>
> Nicola Ken Barozzi wrote:
>
>>
>>
>> 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 ;-)
>> >
>> > 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?
>>
>>
>> The x,y and zs are the Avalon lifecycle interfaces.
>> http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
>>
>> An Avalon Component implements the interfaces it needs.
>> An Avalon Container calls them on the Component honoring the Avalon
>> lifecycle contract defined in the above URL.
>>
>> If you declare all of them in the abstract class, all will be called and
>> possibly not used.
>> This could be bad performance-wise, but it basically defeats the purpose
>> of using the interfaces to declare easily what the Component requires.
>>
>> Anyway, to have more info, there is a booklet about how to develop with
>> Avalon:
>> http://jakarta.apache.org/avalon/developing/developing-with-avalon.pdf
>>
>> Also read all the pages linked at the bottom of this page:
>> http://jakarta.apache.org/avalon/framework/index.html
>>
>> To learn what a container is with an easy learning curve, see Tweety
>> http://jakarta.apache.org/avalon/excalibur/tweety/index.html
>>
>> > 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?
>>
>>
>> Your request is too generic IMHO.
>>
>> Read the above and take a look at two tutorial containers called Egg
>> (look at that firs, it's in the Tweety project) and Tweety itself.
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: avalon newbie: Innocent question, please don't hurt me -- services
strategy with Avalon framework
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I've read all that.. . It left me with a "now what" feeling...
Nicola Ken Barozzi wrote:
>
>
> 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 ;-)
> >
> > 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?
>
>
> The x,y and zs are the Avalon lifecycle interfaces.
> http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
>
> An Avalon Component implements the interfaces it needs.
> An Avalon Container calls them on the Component honoring the Avalon
> lifecycle contract defined in the above URL.
>
> If you declare all of them in the abstract class, all will be called and
> possibly not used.
> This could be bad performance-wise, but it basically defeats the purpose
> of using the interfaces to declare easily what the Component requires.
>
> Anyway, to have more info, there is a booklet about how to develop with
> Avalon:
> http://jakarta.apache.org/avalon/developing/developing-with-avalon.pdf
>
> Also read all the pages linked at the bottom of this page:
> http://jakarta.apache.org/avalon/framework/index.html
>
> To learn what a container is with an easy learning curve, see Tweety
> http://jakarta.apache.org/avalon/excalibur/tweety/index.html
>
> > 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?
>
>
> Your request is too generic IMHO.
>
> Read the above and take a look at two tutorial containers called Egg
> (look at that firs, it's in the Tweety project) and Tweety itself.
>
--
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
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 ;-)
>
> 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?
The x,y and zs are the Avalon lifecycle interfaces.
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
An Avalon Component implements the interfaces it needs.
An Avalon Container calls them on the Component honoring the Avalon
lifecycle contract defined in the above URL.
If you declare all of them in the abstract class, all will be called and
possibly not used.
This could be bad performance-wise, but it basically defeats the purpose
of using the interfaces to declare easily what the Component requires.
Anyway, to have more info, there is a booklet about how to develop with
Avalon:
http://jakarta.apache.org/avalon/developing/developing-with-avalon.pdf
Also read all the pages linked at the bottom of this page:
http://jakarta.apache.org/avalon/framework/index.html
To learn what a container is with an easy learning curve, see Tweety
http://jakarta.apache.org/avalon/excalibur/tweety/index.html
> 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?
Your request is too generic IMHO.
Read the above and take a look at two tutorial containers called Egg
(look at that firs, it's in the Tweety project) and Tweety itself.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: avalon newbie: Innocent question, please don't hurt me -- services
strategy with Avalon framework
Posted by "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>
Re: avalon newbie: Innocent question, please don't hurt me --
services strategy with Avalon framework
Posted by 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
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Hi Adam,
>
>On Fri, 2002-11-15 at 19:39, Adam Rossi wrote:
>
>
>>Stephen, I found your summary descriptions helpful. On thing I am
>>struggling with is how to set a parameter in a component that is needed
>>during Initialiable. For example, if my Company component needs a
>>companyID set before it can initialize, how does the container set the
>>ID before initialize is called? It seems that a name/value pair should
>>be set in the context so that Contextualizable can supply the companyId
>>before it is initialized. I have tried to find an example of this but
>>could not find one. Is this beyond the lifecycle of the container and
>>something that should be done via a set method after I have my object?
>>
>>
>
>nah....it's something you need to do often and it can be easily done
>using the avalon lifecycle.
>
>we've got Parameterizable and Parameters for passing in property-like
>stuff, but the use of that in current container is not quite as easy as
>using Configuration and Configurable.
>
>What you do is provide a xml configuration file, and then that
>configuration is handed in as an object hierarchy (think DOM, but way
>easier to use) to the component by the container (it calls the
>configure() method on your component). This is guaranteed to happen
>before initialize() is called.
>
>(While it is of course possible to put stuff like this in a Context,
>using a Configuration is usually easier and more straightforward for
>data that is naturally represented in XML)
>
>How to do this exactly differs a little per container. If you are using
>phoenix, your best bet is to take a look at how the demo apps do it
>(somewhat out-of-date downloads from
>http://cvs.apache.org/~hammant/apps/, for the most recent stuff you'll
>have to get this from the jakarta-avalon-apps CVS) for clues.
>
>I'm CCing the avalon-user list as that's really the best place for talk
>about this. no worries though ;)
>
>
The above approach only works if the CompanyID value is a static (i.e.
declared i a configuration, or context directive or whatever). If you
have a runtime value, you have to (a) create you own DefaultContext and
handle a compoent deployment, (b) use a component lifecycle extension,
or (c) roll-your-own container.
Cheer, Steve.
see - I can write short messages ;-)
>regards,
>
>- Leo Simons
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: avalon newbie: Innocent question, please don't hurt me --
services strategy with Avalon framework
Posted by Leo Simons <le...@apache.org>.
Hi Adam,
On Fri, 2002-11-15 at 19:39, Adam Rossi wrote:
> Stephen, I found your summary descriptions helpful. On thing I am
> struggling with is how to set a parameter in a component that is needed
> during Initialiable. For example, if my Company component needs a
> companyID set before it can initialize, how does the container set the
> ID before initialize is called? It seems that a name/value pair should
> be set in the context so that Contextualizable can supply the companyId
> before it is initialized. I have tried to find an example of this but
> could not find one. Is this beyond the lifecycle of the container and
> something that should be done via a set method after I have my object?
nah....it's something you need to do often and it can be easily done
using the avalon lifecycle.
we've got Parameterizable and Parameters for passing in property-like
stuff, but the use of that in current container is not quite as easy as
using Configuration and Configurable.
What you do is provide a xml configuration file, and then that
configuration is handed in as an object hierarchy (think DOM, but way
easier to use) to the component by the container (it calls the
configure() method on your component). This is guaranteed to happen
before initialize() is called.
(While it is of course possible to put stuff like this in a Context,
using a Configuration is usually easier and more straightforward for
data that is naturally represented in XML)
How to do this exactly differs a little per container. If you are using
phoenix, your best bet is to take a look at how the demo apps do it
(somewhat out-of-date downloads from
http://cvs.apache.org/~hammant/apps/, for the most recent stuff you'll
have to get this from the jakarta-avalon-apps CVS) for clues.
I'm CCing the avalon-user list as that's really the best place for talk
about this. no worries though ;)
regards,
- Leo Simons
--
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
Posted by Stephen McConnell <mc...@apache.org>.
[cross-posting from Avalon Dev to Avalon User]
Adam Rossi wrote:
>Stephen, I found your summary descriptions helpful. On thing I am
>struggling with is how to set a parameter in a component that is needed
>during Initialiable. For example, if my Company component needs a
>companyID set before it can initialize, how does the container set the
>ID before initialize is called? It seems that a name/value pair should
>be set in the context so that Contextualizable can supply the companyId
>before it is initialized. I have tried to find an example of this but
>could not find one. Is this beyond the lifecycle of the container and
>something that should be done via a set method after I have my object?
>
You can do what you describe though a lifecycle extension. There are
examples of the application of compoent lifecycle extensions in both
Fortress and Merlin and documetation for both under the following URL:
http://jakarta.apache.org/avalon/excalibur/container/extension.html
If have have a situation where code has runtime information that is
needed by a component to function, then your basically describing
something in container-land. As such, you need to think of in terms of
your code acting as a container, and deploying components as required,
and supplied with appropriate runtime information. The component
lifecycle extension architecture does exactly this - it enables the
seperation of a container side handler from the component-side lifecycle
interface.
That was the quick answer - here is the longer answer that also
addresses the point about container verus component seperation.
Unlike the framework interfaces, an Avalon Container API does not exist.
However, there are iniatives such as the Fortress and Merlin work which
specifically address embedded components, and varying levels of
functional container-side services. There is also more application
level content within the Phoenix project. If you look into all of this
content you can basically break down the container-side concerns to the
following:
1. logging management
- logging system bootstrapping
- logging channel creation
- management of logging targets
2. context management
- context criteria management
- context export from a container to a component
- declarative context generation
3. configuration management
- classic configuration loading
- default configuration handling
- cascading configurations
- verifiable configurations
4. component assembly
- building associations based on services and depedencies
- validation of assemblies
- assembly packaging
5. lifecycle processing
- management of the classic Avalon lifecycle
- extension management
6. lifestyle handling
- management of object pools
- per thread policies
- named providers
- transient components
7. deployment
- classloader management
- containment strategy
- service propergation
8. activation
- deferred activation
- service interface proxying
- principal identity
- policy management
In your example, you have a company identifier, presumably aquired
through some runtime parameter, and you need to launch a component and
supply it with that parameter, probably as a keyed value with the
context object.
The simplest approach is just create you new component, create a context
object, add the CompanyID to the context object, then contextualize the
component. The problem with this approach is that your creating a tight
binding between your container code and the component your deploying.
For example, if you add support for logging on your component, you need
to go back to you container-side code and make sure the component is
given a logger. I.e. your container-side code becomes tightly bound to a
component implemetation.
The alternative is to use a container-side framework that provides the
type of services I've listed above. As I mentioned above, there isn't
an Avalon Container API which means you either leverage something like
Fortress or Merlin, or your role-you-own container management solution
using things like excalibur/configuration, excalibur/extension,
excalibur/container, excalibur/meta and so forth.
If you need any help with exploring the lifecycle extension approach,
don't hesitate to post an email avalon-users. As to further sicussions
on a Avalon Container API - that something more appropriate under
avalon-dev.
Hope that helps.
Cheers, Steve.
>Thanks,
>
>Adam
>
>On Fri, 2002-11-15 at 11:51, Stephen McConnell wrote:
><snip>
>
>
>> Contextualizable
>>
>> supply of the runtime context - again, the
>> context information that the component needs
>> (key + type) can be declared in meta info so
>> a container can make sure the component gets
>> all of the context information it needs
>>
>> Configurable
>>
>> supply of the component configuration by the
>> to the component.
>>
>> Initialiable
>>
>> request from the container to the component
>> to initialize itself, typically the
>> component implemetation will validate internal
>> state at this point
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: avalon newbie: Innocent question, please don't hurt me --
services strategy with Avalon framework
Posted by Adam Rossi <ad...@platinumsolutions.com>.
Stephen, I found your summary descriptions helpful. On thing I am
struggling with is how to set a parameter in a component that is needed
during Initialiable. For example, if my Company component needs a
companyID set before it can initialize, how does the container set the
ID before initialize is called? It seems that a name/value pair should
be set in the context so that Contextualizable can supply the companyId
before it is initialized. I have tried to find an example of this but
could not find one. Is this beyond the lifecycle of the container and
something that should be done via a set method after I have my object?
Thanks,
Adam
On Fri, 2002-11-15 at 11:51, Stephen McConnell wrote:
<snip>
> Contextualizable
>
> supply of the runtime context - again, the
> context information that the component needs
> (key + type) can be declared in meta info so
> a container can make sure the component gets
> all of the context information it needs
>
> Configurable
>
> supply of the component configuration by the
> to the component.
>
> Initialiable
>
> request from the container to the component
> to initialize itself, typically the
> component implemetation will validate internal
> state at this point
>
>
--
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
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I'm not buying it until you point me to a real project that is a good
example of this done right and that hasn't suffered from excess
complexity. Then I'll buy it ;-)
-Andy
Stephen McConnell wrote:
>
>
> Andrew C. Oliver wrote:
>
> > Okay so you've hooked me.
>
>
>
> :-)
>
> > Show me a set of code that you regard as WELL designed and
> > UNDERSTANDABLE (which means maintainable over time as well). My
> > biggest problem with the approach you suggest is the only examples I
> > have of code that was done in that way I seriously seriously seriously
> > dislike. I also have a gripe against excessive "is a" relationships
> > but putting that aside. Point me to something that was done well that
> > uses the framework in the manner you suggest.
>
>
>
> All of the containers in Avalon (Merlin, Fortress, Phoenix) have been
> built the patterns I've described. But I don't think that's a good
> solution in terms of pointing you to something because it will be really
> easy to get mixed up about things because you will be looking at
> component based systems proving component management.
> There are examples of Phoneix components that follow this pattern in the
> cornerstone package, and the james is an example of a system based on
> the composition of components - but you should probably post an email to
> the Phoenix list to get suggestions on which of these components you
> should be looking at.
>
> I have a lot of stuff I'm working on that's internal that meets your
> criteria. But to get to this position I've had to build the container
> API to provide the proper seperation of container-side verus component
> concerns. I'm not saying there isn't well designed and understandable
> systems out there based on Avalon, but I do think that these examples
> will be of limited complexity. Without these sort of container-side
> service abstractions the code in a complex system starts to get
> complicated with component management artifacts - in other words -
> things get cluttered and unnecessarily complicated. Based on the work
> with excalibur/assembly, meta, container, configuration, I've managed to
> substantially simplify my code base and get a big application under
> control and readily understandable.
>
> Cheers, Steve.
>
> >
> >
> > -andy
> >
> > Stephen McConnell wrote:
> >
> >>
> >>
> >> 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 ;-)
> >> >
> >> > 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?
> >>
> >>
> >> Probably:
> >>
> >> LogEnabled,
> >> Initializable,
> >> Disposable
> >>
> >> But if you wanted to do the grand abstract approach, you could do
> >> something like:
> >>
> >> LogEnabled,
> >> Serviceable,
> >> Contextualizable,
> >> Configurable,
> >> Initializable,
> >> Startable,
> >> Disposable
> >>
> >> But I also think it is bad approach. I'll explain why.
> >> Creation of abstract class is something that makes sence when the
> >> underlying functionality is "rich". That isn't the case with any
> of the
> >> above - as you will have seen from Leo's email you just end up with an
> >> object holding a bunch of state members. What's missing is the
> >> relationship between that object and its container. All of the above
> >> interface provide the formal points of inteaction between a container
> >> and a component.
> >>
> >> LogEnabled
> >>
> >> assignment of the logging channel that
> >> the component will use (component does
> >> not see any particular logging implemetation)
> >>
> >> Serviceable
> >>
> >> assignment of the services that the compoent
> >> needs to function to do its job (component
> >> should never need to go hunting for the service
> >> it neeeds) - service that the component needs
> >> would typically be declared as depedencies in
> >> a meta declaration and the container will take
> >> care of service provisioning
> >>
> >> Contextualizable
> >>
> >> supply of the runtime context - again, the
> >> context information that the component needs
> >> (key + type) can be declared in meta info so
> >> a container can make sure the component gets
> >> all of the context information it needs
> >>
> >> Configurable
> >>
> >> supply of the component configuration by the
> >> to the component.
> >>
> >> Initialiable
> >>
> >> request from the container to the component
> >> to initialize itself, typically the
> >> component implemetation will validate internal
> >> state at this point
> >>
> >> Startable
> >>
> >> only applicable in the case of a component that
> >> needss to start up its own thread of execution
> >> (i.e. a component acting as a server for example)
> >> - called by the container to instruct the component
> >> to start or stop doing its stuff
> >>
> >> Disposable
> >>
> >> Used by a container to tell the compoent to clean
> >> up state
> >>
> >> Problem with the "AbstractService" approach is the abstract work should
> >> be in the container, not in the component. It the container that
> has to
> >> take care of doing all of the leg work to make sure the component gets
> >> everything it needs. It does this based on a combination of (a)
> >> lifecycle interfaces as described above, and (b) supplimentary meta
> >> information describing the component deployment criteria.
> >>
> >> By pushing all of the overhead onto the container, you end up with much
> >> better code in you component implemetation, and much less code.
> >>
> >>
> >> > And what else do I need?
> >>
> >>
> >>
> >> 1. a container
> >> 2. a component / service model (design)
> >>
> >> >
> >> > 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?
> >>
> >>
> >>
> >> Doing cause-grained component oriented development is an approach that
> >> lets you break apart systems more formally, and from that, the overall
> >> system (a set of assembled components) becomes much, much simpler to
> >> build. In fact, combining the Avalon component model with meta
> >> information enables the automation of system assembly and deployment.
> >>
> >> Cheers, Steve.
> >>
> >> >
> >> > thanks,
> >> >
> >> > Andy
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > To unsubscribe, e-mail:
> >> >
> >> > For additional commands, e-mail:
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> >
> > For additional commands, e-mail:
> >
> >
> >
> >
>
--
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
Posted by Stephen McConnell <mc...@apache.org>.
Andrew C. Oliver wrote:
> Okay so you've hooked me.
:-)
> Show me a set of code that you regard as WELL designed and
> UNDERSTANDABLE (which means maintainable over time as well). My
> biggest problem with the approach you suggest is the only examples I
> have of code that was done in that way I seriously seriously seriously
> dislike. I also have a gripe against excessive "is a" relationships
> but putting that aside. Point me to something that was done well that
> uses the framework in the manner you suggest.
All of the containers in Avalon (Merlin, Fortress, Phoenix) have been
built the patterns I've described. But I don't think that's a good
solution in terms of pointing you to something because it will be really
easy to get mixed up about things because you will be looking at
component based systems proving component management.
There are examples of Phoneix components that follow this pattern in the
cornerstone package, and the james is an example of a system based on
the composition of components - but you should probably post an email to
the Phoenix list to get suggestions on which of these components you
should be looking at.
I have a lot of stuff I'm working on that's internal that meets your
criteria. But to get to this position I've had to build the container
API to provide the proper seperation of container-side verus component
concerns. I'm not saying there isn't well designed and understandable
systems out there based on Avalon, but I do think that these examples
will be of limited complexity. Without these sort of container-side
service abstractions the code in a complex system starts to get
complicated with component management artifacts - in other words -
things get cluttered and unnecessarily complicated. Based on the work
with excalibur/assembly, meta, container, configuration, I've managed to
substantially simplify my code base and get a big application under
control and readily understandable.
Cheers, Steve.
>
>
> -andy
>
> Stephen McConnell wrote:
>
>>
>>
>> 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 ;-)
>> >
>> > 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?
>>
>>
>> Probably:
>>
>> LogEnabled,
>> Initializable,
>> Disposable
>>
>> But if you wanted to do the grand abstract approach, you could do
>> something like:
>>
>> LogEnabled,
>> Serviceable,
>> Contextualizable,
>> Configurable,
>> Initializable,
>> Startable,
>> Disposable
>>
>> But I also think it is bad approach. I'll explain why.
>> Creation of abstract class is something that makes sence when the
>> underlying functionality is "rich". That isn't the case with any of the
>> above - as you will have seen from Leo's email you just end up with an
>> object holding a bunch of state members. What's missing is the
>> relationship between that object and its container. All of the above
>> interface provide the formal points of inteaction between a container
>> and a component.
>>
>> LogEnabled
>>
>> assignment of the logging channel that
>> the component will use (component does
>> not see any particular logging implemetation)
>>
>> Serviceable
>>
>> assignment of the services that the compoent
>> needs to function to do its job (component
>> should never need to go hunting for the service
>> it neeeds) - service that the component needs
>> would typically be declared as depedencies in
>> a meta declaration and the container will take
>> care of service provisioning
>>
>> Contextualizable
>>
>> supply of the runtime context - again, the
>> context information that the component needs
>> (key + type) can be declared in meta info so
>> a container can make sure the component gets
>> all of the context information it needs
>>
>> Configurable
>>
>> supply of the component configuration by the
>> to the component.
>>
>> Initialiable
>>
>> request from the container to the component
>> to initialize itself, typically the
>> component implemetation will validate internal
>> state at this point
>>
>> Startable
>>
>> only applicable in the case of a component that
>> needss to start up its own thread of execution
>> (i.e. a component acting as a server for example)
>> - called by the container to instruct the component
>> to start or stop doing its stuff
>>
>> Disposable
>>
>> Used by a container to tell the compoent to clean
>> up state
>>
>> Problem with the "AbstractService" approach is the abstract work should
>> be in the container, not in the component. It the container that has to
>> take care of doing all of the leg work to make sure the component gets
>> everything it needs. It does this based on a combination of (a)
>> lifecycle interfaces as described above, and (b) supplimentary meta
>> information describing the component deployment criteria.
>>
>> By pushing all of the overhead onto the container, you end up with much
>> better code in you component implemetation, and much less code.
>>
>>
>> > And what else do I need?
>>
>>
>>
>> 1. a container
>> 2. a component / service model (design)
>>
>> >
>> > 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?
>>
>>
>>
>> Doing cause-grained component oriented development is an approach that
>> lets you break apart systems more formally, and from that, the overall
>> system (a set of assembled components) becomes much, much simpler to
>> build. In fact, combining the Avalon component model with meta
>> information enables the automation of system assembly and deployment.
>>
>> Cheers, Steve.
>>
>> >
>> > thanks,
>> >
>> > Andy
>> >
>> >
>> >
>> >
>> > --
>> > To unsubscribe, e-mail:
>> >
>> > For additional commands, e-mail:
>> >
>> >
>> >
>> >
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: avalon newbie: Innocent question, please don't hurt me -- services
strategy with Avalon framework
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Okay so you've hooked me. Show me a set of code that you regard as WELL
designed and UNDERSTANDABLE (which means maintainable over time as
well). My biggest problem with the approach you suggest is the only
examples I have of code that was done in that way I seriously seriously
seriously dislike. I also have a gripe against excessive "is a"
relationships but putting that aside. Point me to something that was
done well that uses the framework in the manner you suggest.
-andy
Stephen McConnell wrote:
>
>
> 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 ;-)
> >
> > 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?
>
>
> Probably:
>
> LogEnabled,
> Initializable,
> Disposable
>
> But if you wanted to do the grand abstract approach, you could do
> something like:
>
> LogEnabled,
> Serviceable,
> Contextualizable,
> Configurable,
> Initializable,
> Startable,
> Disposable
>
> But I also think it is bad approach. I'll explain why.
> Creation of abstract class is something that makes sence when the
> underlying functionality is "rich". That isn't the case with any of the
> above - as you will have seen from Leo's email you just end up with an
> object holding a bunch of state members. What's missing is the
> relationship between that object and its container. All of the above
> interface provide the formal points of inteaction between a container
> and a component.
>
> LogEnabled
>
> assignment of the logging channel that
> the component will use (component does
> not see any particular logging implemetation)
>
> Serviceable
>
> assignment of the services that the compoent
> needs to function to do its job (component
> should never need to go hunting for the service
> it neeeds) - service that the component needs
> would typically be declared as depedencies in
> a meta declaration and the container will take
> care of service provisioning
>
> Contextualizable
>
> supply of the runtime context - again, the
> context information that the component needs
> (key + type) can be declared in meta info so
> a container can make sure the component gets
> all of the context information it needs
>
> Configurable
>
> supply of the component configuration by the
> to the component.
>
> Initialiable
>
> request from the container to the component
> to initialize itself, typically the
> component implemetation will validate internal
> state at this point
>
> Startable
>
> only applicable in the case of a component that
> needss to start up its own thread of execution
> (i.e. a component acting as a server for example)
> - called by the container to instruct the component
> to start or stop doing its stuff
>
> Disposable
>
> Used by a container to tell the compoent to clean
> up state
>
> Problem with the "AbstractService" approach is the abstract work should
> be in the container, not in the component. It the container that has to
> take care of doing all of the leg work to make sure the component gets
> everything it needs. It does this based on a combination of (a)
> lifecycle interfaces as described above, and (b) supplimentary meta
> information describing the component deployment criteria.
>
> By pushing all of the overhead onto the container, you end up with much
> better code in you component implemetation, and much less code.
>
>
> > And what else do I need?
>
>
>
> 1. a container
> 2. a component / service model (design)
>
> >
> > 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?
>
>
>
> Doing cause-grained component oriented development is an approach that
> lets you break apart systems more formally, and from that, the overall
> system (a set of assembled components) becomes much, much simpler to
> build. In fact, combining the Avalon component model with meta
> information enables the automation of system assembly and deployment.
>
> Cheers, Steve.
>
> >
> > thanks,
> >
> > Andy
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> >
> > For additional commands, e-mail:
> >
> >
> >
> >
>
--
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
Posted by Stephen McConnell <mc...@apache.org>.
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 ;-)
>
> 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?
Probably:
LogEnabled,
Initializable,
Disposable
But if you wanted to do the grand abstract approach, you could do
something like:
LogEnabled,
Serviceable,
Contextualizable,
Configurable,
Initializable,
Startable,
Disposable
But I also think it is bad approach.
I'll explain why.
Creation of abstract class is something that makes sence when the
underlying functionality is "rich". That isn't the case with any of the
above - as you will have seen from Leo's email you just end up with an
object holding a bunch of state members. What's missing is the
relationship between that object and its container. All of the above
interface provide the formal points of inteaction between a container
and a component.
LogEnabled
assignment of the logging channel that
the component will use (component does
not see any particular logging implemetation)
Serviceable
assignment of the services that the compoent
needs to function to do its job (component
should never need to go hunting for the service
it neeeds) - service that the component needs
would typically be declared as depedencies in
a meta declaration and the container will take
care of service provisioning
Contextualizable
supply of the runtime context - again, the
context information that the component needs
(key + type) can be declared in meta info so
a container can make sure the component gets
all of the context information it needs
Configurable
supply of the component configuration by the
to the component.
Initialiable
request from the container to the component
to initialize itself, typically the
component implemetation will validate internal
state at this point
Startable
only applicable in the case of a component that
needss to start up its own thread of execution
(i.e. a component acting as a server for example)
- called by the container to instruct the component
to start or stop doing its stuff
Disposable
Used by a container to tell the compoent to clean
up state
Problem with the "AbstractService" approach is the abstract work should
be in the container, not in the component. It the container that has to
take care of doing all of the leg work to make sure the component gets
everything it needs. It does this based on a combination of (a)
lifecycle interfaces as described above, and (b) supplimentary meta
information describing the component deployment criteria.
By pushing all of the overhead onto the container, you end up with much
better code in you component implemetation, and much less code.
> And what else do I need?
1. a container
2. a component / service model (design)
>
> 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?
Doing cause-grained component oriented development is an approach that
lets you break apart systems more formally, and from that, the overall
system (a set of assembled components) becomes much, much simpler to
build. In fact, combining the Avalon component model with meta
information enables the automation of system assembly and deployment.
Cheers, Steve.
>
> thanks,
>
> Andy
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>